MariaDB student database projects for Constructor University (2026-08)

MariaDB is an open-source relational database, forked from MySQL in 2009 and developed independently since into a database with its own unique features — read more on Wikipedia, which incidentally runs on MariaDB.

Below are twenty areas to build a project within. Each says what the MariaDB feature is, what you would build, and what the project has to show to count as done. The areas are ordered by how much it costs to get started: a single local server first, then an extra service or a heavier install, then several servers at once, and at the end territory nobody has mapped yet.

Instructions

Pick one area and name it in your README.
MariaDB is the database throughout, whichever area you pick. Every area is built around something MariaDB does that other databases do not, and that is the point of the exercise.
Deliver a public GitHub repository, with the code on the main branch and README.md at the root.
The README carries the project: a summary; how to run or reproduce it, including requirements, MariaDB setup and loading the data; screenshots and illustrations; observations and conclusions; and how it was built: architecture, features, team.
Run MariaDB however you like — local install, Docker image, cloud instance. State the version you developed against. Preview releases are fine; just pin one and say so.
Bring data. mariadb/openflights is a possible data set, or a public data set like Wikipedia, or data you generate yourself. The repo must contain the data or a repeatable way to fetch and load it. If your area needs volume, openflights is small — bring more.
Four things are evaluated, and they count equally: the documentation in the README, MariaDB depth, execution (code, research, measurements), and usability (how usable the repo is as a feature tutorial). We will share an evaluation prompt for transparency.

Tier A — start here

One local server, nothing else to install. You will have something working the first evening.

1. SQL that saves you work

The feature. A set of small SQL features that remove work you would otherwise do in application code. Each is minor on its own; together they change how much you have to write.

INET4 and INET6 — native IP address types. Four and sixteen bytes instead of a string, and they sort and compare the way addresses should.
UUID — a real UUID type, not CHAR(36) and not a BINARY(16) you encode by hand.
RETURNING — INSERT, UPDATE and DELETE hand back the rows they touched, so the second round trip disappears.
CREATE SEQUENCE — sequences as first-class objects, independent of any table’s AUTO_INCREMENT.
INTERSECT and EXCEPT — the set operations that belong next to UNION.
CREATE OR REPLACE — idempotent DDL, so migration scripts stop opening with a DROP ... IF EXISTS dance.
IS JSON — the SQL-standard predicate for testing that a document really is JSON, usable inside a CHECKconstraint.
Invisible columns — columns that stay out of SELECT * and out of INSERT without a column list, but are there the moment you name them.
The ROW type — composite variables in stored routines, so a procedure can pass a whole row around instead of a dozen scalars.
Instant ADD, DROP and MODIFY COLUMN — schema changes that complete immediately on a large table instead of rebuilding it.
Progress reporting — long ALTER TABLE and CHECK TABLE tell you how far they have got.
Global temporary tables (12.3) — SQL-standard: one shared definition, contents private to each session.
UPDATE and DELETE that read from CTEs (12.3) — a WITH clause feeding the statement that changes the data.

The project. Choose at least two of them and build something that genuinely leans on your choices — then show what the same code looks like without them: the extra round trip, the string column that sorts wrong, the migration script full of DROP TABLE IF EXISTS, the validation that lives in application code because the database would not do it for you.

Goal. Make the case concrete: fewer queries, less application code, a schema that enforces more of its own rules. This one lives or dies on the before/after comparison — two features compared honestly beat seven merely listed.

2. Custom aggregate functions in SQL

The feature. CREATE AGGREGATE FUNCTION lets you write your own aggregate in SQL, using stored-routine syntax and FETCH GROUP NEXT ROW to walk the rows of the current group. MySQL has no SQL-level equivalent — there you write a C UDF or you do without.

The project. Implement at least one of the aggregates SQL is famous for lacking, and put it to work on a real dataset:

Median — and, once you have it, any percentile you like.
Mode — the most common value in a group.
Geometric mean — for growth rates and ratios, where the arithmetic mean lies to you.
Gini coefficient — concentration or inequality within a group.
A weighted percentile — where each row carries its own weight.
Longest streak — the longest run of consecutive days, wins or failures in a group.
Or one of your own, if your dataset suggests something better.

For each one you implement, show the contortion it replaces: the window function, the correlated subquery, or the application-side loop you would otherwise need.

Goal. Make the feature earn its place with a side-by-side comparison — query length, readability and execution time, with and without. A small, well-chosen function library beats a large careless one.

3. System-versioned tables: history for free

The feature. WITH SYSTEM VERSIONING makes a table keep its own history, queryable withFOR SYSTEM_TIME AS OF, BETWEEN and ALL. Application-time periods model validity ranges independently of when rows were written. Both are SQL:2011 standard, built into the server.

The project. Build a time machine for Wikipedia. Take a dump of a selected set of articles — a few dozen is plenty — with their revision history, from dumps.wikimedia.org or the MediaWiki API, load them into a system-versioned table, and give the reader a page where they pick a moment in time and see the article as it stood then. Add a diff between two chosen times if you have room. Include the operational side: how the versioned table grows, and how partitioning by SYSTEM_TIME keeps it manageable.

There is a nice irony to lean on in the README. Wikipedia runs on MariaDB, and keeps its history in application-level revision tables written years before system versioning existed. Your version lets the database do it in one clause.

Note. Decide early how the historical dates are represented, because it is the real design question here. System versioning stamps a row when the transaction runs, so a naive import gives you a perfect history of your own loading script and nothing about the article. Your options are to replay the revisions in order and accept import-time stamps, to write history rows directly with their true timestamps using system_versioning_insert_history, or to model the revision dates as an application-time period alongside the system period. The last is the most interesting answer — and explaining the choice belongs in the README.

Goal. Replace what would otherwise be revision tables, triggers and application code with a table definition, and show the querying that becomes possible once you have it: any past state, any two states compared, in ordinary SQL.

4. Vector search and RAG, natively

The feature. MariaDB 11.8 LTS shipped a native VECTOR type with HNSW indexing and SIMD acceleration, integrated with LangChain, LlamaIndex, Spring AI and LangChain4j. Vector indexing lives inside the transactional database — not a separate service to keep in sync, not an extension to install.

The project. Build retrieval over Wikipedia. Take a set of articles from dumps.wikimedia.org or the MediaWiki API — one category, one subject area, or a few hundred articles you find interesting — chunk the text, embed the chunks, and store the vectors next to the article metadata with a VECTOR INDEX over them. Query with VEC_DISTANCE_COSINE.

Then do the thing a dedicated vector database cannot: constrain the semantic search with ordinary SQL in the same statement — only articles in this category, longer than this, edited since that date, linked from that other article — and join the results back to your relational tables, transactionally consistent with the vectors.

Note. The decisions worth documenting are chunk size and overlap, the embedding model and why you chose it, and the index parameters. Build a small ground-truth set — questions whose correct source article you already know — so that “it works well” becomes a number.

Goal. Show hybrid search that a bolt-on vector store cannot do, and measure recall and latency honestly rather than asserting them. INFORMATION_SCHEMA.VECTOR_INDEXES (13.1) gives you the index metadata to report against.

5. Authentication and access control

The feature. SSL on by default with no configuration, ED25519 and PARSEC elliptic-curve authentication, Unix socket authentication, roles, and password validation and reuse plugins. MariaDB 13.1 adds DENY — negative grants, so you can say “everything in this schema except that table” instead of enumerating every table you do allow, and the denial stays visible to the next administrator who audits it. Neither MySQL nor PostgreSQL has it.

The project. Build an application with a real access-control model: roles and DENY rather than enumerated per-user grants; one of the authentication methods named above rather than a password sitting in a configuration file; TLS verified rather than assumed. Then attack it — show what each control actually prevents.

Goal. Demonstrate a database that is secure by configuration rather than by convention, and make the reader able to reproduce the setup.

Tier B — build something substantial

Still a single server. The difficulty is engineering and rigour rather than setup.

6. Choosing the right storage engine

The feature. MariaDB lets you pick the storage engine per table — InnoDB, Aria, MyRocks, ColumnStore, MEMORY, ARCHIVE — while the SQL you write stays the same.

The project. Build one dataset and one workload harness, then run the same schema across several engines and measure what actually changes: load time, on-disk size, point-lookup latency, full-scan time, concurrent write throughput, crash recovery behaviour. To the extent the openflights data set is insufficient for illustrating the properties, identify and use a suitable complementary data set.

Goal. A demo that makes the trade-offs visible and surprising rather than quoted from a manual — the reader should finish it able to choose an engine for a workload they describe to you, and understand why “just use InnoDB” is usually right and occasionally expensive.

7. The optimizer, opened up

The feature. MariaDB 11.0 completed a rewrite making nearly every optimizer decision cost-based, with tunable costs calibrated for modern hardware. ANALYZE SELECT reports what actually happened rather than what was predicted; histograms, index condition pushdown, block hash joins, table elimination and subquery caching sit underneath.

The project. Build a query workbench: a schema and a set of queries where plan choice genuinely matters, then show EXPLAIN against ANALYZE SELECT, the effect of histogram statistics, and what happens when you change optimizer cost settings. Find a query where the optimizer chooses wrongly and explain why. The Optimizer Context Recorder (13.1) captures a planning context on one server so you can analyse it on another — build your workbench around it.

Goal. Teach the reader to read a plan and to diagnose a slow query with evidence instead of guesswork.

8. Online schema change, without external tools

The feature. MariaDB’s native online DDL — ALGORITHM=COPY, LOCK=NONE, available since 11.2 — rebuilds a table while INSERT, UPDATE and DELETE keep running, capturing concurrent changes in server-managed buffers instead of the triggers that pt-online-schema-change has to install. Long ALTER TABLE and CHECK TABLE report their progress while they run.

The project. Build a migration laboratory: a table large enough to matter, a continuous write workload against it, and a series of schema changes of increasing awkwardness — widen a column, add an index, change a type, add a foreign key. Measure duration, lock waits, replication impact and error paths for each, against ALGORITHM=INPLACE where it applies and against a naive blocking ALTER TABLE.

Goal. A table of which schema changes are safe to run on a live system and which are not, backed by numbers rather than by folklore — and an explanation of what the server is doing underneath.

Tier C — external systems and heavier installs

An extra service to stand up, a heavier install, or somebody else’s codebase to read.

9. FLASHBACK: undo without a restore

The feature. FLASHBACK rolls data back to an earlier state using the binary log — originally contributed by Alibaba — without restoring a backup.

The project. Build a realistic disaster and a recovery tool around it: the UPDATE without a WHERE clause, the deployment that corrupted a table. Recover to a point in time, verify the result, and measure how long it took against a full restore.

Goal. Show the recovery path most teams do not know they have, and be precise about its limits — what FLASHBACK can and cannot undo, and what binlog configuration it requires.

10. Encryption and key management

The feature. Table and tablespace encryption at rest, with keys managed by a file plugin, HashiCorp Vault, or AWS KMS. The binary log and temporary files can be encrypted too.

The project. Encrypt a real dataset, integrate a key manager, and rotate a key while the server is serving traffic. Measure the performance cost. Show what an attacker with the data files sees before and after.

Goal. Encryption at rest that is set up correctly and understood — including the part most guides skip, which is what happens to your data when the key manager is unavailable.

11. Write a server plugin

The feature. MariaDB’s plugin API lets you extend the server itself rather than the application on top of it: audit plugins, authentication plugins, INFORMATION_SCHEMA tables, native aggregate functions, storage engines, even new data types. 2026 lowered the barrier considerably — plugins can now be written in more languages, and there are worked walkthroughs from an audit plugin in three minutes to adding a data type with Type_handler.

The project. Build and install a plugin that does something real: an audit plugin that records one event class the way your organisation would want it recorded, an INFORMATION_SCHEMA table exposing something the server does not surface today, or a native aggregate function too hot to write in SQL.

Note. You need a C/C++ toolchain and the server headers. Budget the first days for getting an empty skeleton plugin to compile and load — after that the work goes quickly.

Goal. A plugin someone else can build, install and use, with a README that makes that possible. This is extending the database rather than using it.

12. ColumnStore: analytics without a second database

The feature. ColumnStore stores data column-wise and is built for scans and aggregation over large tables, inside the same server that holds your transactional tables.

The project. Take a genuinely large public dataset, keep the operational tables in InnoDB and the analytical ones in ColumnStore, and build reporting that joins across both. Show query plans and timings against an InnoDB-only baseline.

Goal. Demonstrate the thing that is otherwise an ETL pipeline into a separate warehouse: transactional and analytical workloads in one database, one connection, one SQL dialect.

13. CONNECT: external and legacy data as tables

The feature. The CONNECT engine exposes external things — CSV, XML, JSON files, ODBC sources, other databases, even remote REST endpoints — as ordinary MariaDB tables you can join against.

The project. Build something that unifies data that does not want to be unified: a legacy export format, a live external database, and a local table, queried together in a single statement. Handle the failure modes when the external source is slow, absent or malformed.

Goal. Show federation without an ingest pipeline, and be honest in the README about what it costs — pushdown limits, no indexes on the far side, what breaks under load.

14. Ecosystem compatibility

The feature. MariaDB passed MySQL in WordPress installations in 2025; Drupal and Nextcloud recommend it; Adobe Commerce is moving to it by default. ecohub.mariadb.org lists compatible projects — and many more projects could have their compatibility verified.

The contribution process is now documented end to end, and Headout’s story shows the path from a production problem to a merged patch.

The project. Take an open source project that has not been verified against MariaDB. Run its test suite, find where it assumes MySQL, and fix what breaks — then go further and add something MariaDB can do that the project does not use today: system-versioned history for its records, a vector or FULLTEXT search over its content, an INFORMATION_SCHEMA-driven admin view. Submit what you find upstream.

Note. Compatibility work on its own demonstrates no MariaDB-unique capability — it is the added feature that satisfies section 4.2, so plan for it from the start. Difficulty also depends entirely on which project you pick: it can be an afternoon or a brick wall. Scope it before you commit — clone it, run its test suite against MariaDB, and see what you get.

Goal. A real contribution to a real project, with evidence. The deliverable is the test run, the diagnosis and the patch or issue — not a screenshot of the application starting.

Tier D — multiple servers

Several MariaDB instances in containers or VMs. Budget time for the infrastructure before the project itself starts.

15. Parallel replication and replication lag

The feature. Parallel replication applies changes concurrently on the replica; delayed replicas hold changes back deliberately; annotated row events and binlog checksums make what is flowing legible.

The project. Build a lag laboratory: a write workload heavy enough to make a single-threaded replica fall behind, then measure how much parallel replication recovers and where it stops helping. Visualise lag over time under different settings.

Goal. Turn “replication lag” from a word into a number the reader can reason about, with a clear account of which workloads parallelise and which do not.

16. Galera Cluster: multi-primary that is actually in the server

The feature. Galera provides virtually synchronous multi-primary replication, built into MariaDB rather than added alongside it.

The project. Run a three-node cluster, write to all nodes, and then break things on purpose: kill a node, partition the network, force a certification conflict. Show what the application sees in each case and how it recovers. Do you notice non-causal or phantom reads, and is there a solution to avoid them?

Goal. An honest demonstration of what “virtually synchronous” means, including the conflicts and the write-set limits — the failure behaviour is the interesting part, not the happy path.

17. S3 and cold data

The feature. The S3 storage engine keeps read-only tables in object storage while they remain queryable through normal SQL.

The project. Build a data lifecycle: hot data in InnoDB, aged partitions moved to S3-backed tables, queries that span both without the application changing. Measure the latency and cost difference.

Goal. Show archival that stays queryable — the alternative being a dump file nobody can query and everybody is afraid to delete.

18. Spider: one logical table across many servers

The feature. The Spider engine shards a table across multiple MariaDB backends and makes them look like one table to the application.

The project. Stand up several backends (containers are fine), shard a table by key across them, and build an application that neither knows nor cares. Then make the data redundant with Galera: run each shard as a small Galera cluster rather than a single server, so the same rows live on more than one node. Then kill one node deliberately and document exactly what the application sees — while it is down, and after it rejoins.

Note. Spider used to do the redundancy itself: several links per partition, written as srv "backend1 backend2" with a link_status for each. That feature was deprecated in 10.7.5 and removed (MDEV-28479), and the documentation now points at replication or Galera instead. Galera is the route to take here — and explaining in the README why the built-in one is gone is part of the exercise, because knowing which parts of a feature are still supported is part of using it.

Goal. A working demonstration of transparent sharding, including its limits — cross-shard joins, transactions, and what happens when a shard is unreachable but its copy is not.

Tier E — the deep end

Rare and sparsely documented. Genuinely exploratory: careful, well-documented findings count as a result here.

19. Oracle compatibility and incremental migration

The feature. sql_mode=ORACLE gives you a large subset of PL/SQL — stored procedures, packages, Oracle NULL semantics, NVL(), DECODE(), ROWNUM(), Oracle type synonyms — so an Oracle application can move piece by piece instead of all at once.

The project. Take real PL/SQL (there is plenty of public sample code), run it against MariaDB in Oracle mode, and document precisely what worked, what needed changing, and what has no equivalent. A migration guide with a working example is a better deliverable than an application.

Goal. Show why this makes migration a project rather than a rewrite, and produce something another team could actually follow.

20. DuckDB inside MariaDB

The feature. A pluggable storage engine brings DuckDB’s columnar analytical engine into MariaDB Server — the 2009 architecture still paying dividends in 2026.

Start from the Foundation’s first look at the engine.

The project. Put an analytical workload through it, compare against InnoDB and, if you take the ColumnStore area as well, against that. Document what works today, what does not, and where the engine boundary shows.

Goal. A genuinely current evaluation of a new engine. This one is exploratory: a careful, well-documented “here is what I found, including the rough edges” is a strong result.