Program 14 of 7 · Databases

Specialized & Multi-Model Databases

5,379 words24 min read

Go beyond relational and columnar engines: twelve database families, from document, key-value, graph, and time-series to vector, search, NewSQL, and multi-model, each with a distinct enterprise use case and an end-to-end prototype you build.

MongoDBRedisCassandraNeo4jElasticsearchMilvusCockroachDB
Enroll or ask a question See all 14 programs
Specialized & Multi-Model Databases: the syllabus at a glance1Documents,keys, andwide-column2Graph,time-series,and objects3Analytical,distributed,and in-memory4Vector, search,and multi-modelProject

Beyond one kind of database

Most engineers learn one or two databases and reach for them by habit. The strongest platform engineers know the whole landscape and choose deliberately, because the right database for a workload can make the difference between a system that scales gracefully and one that fights its own storage layer. This program builds that breadth across twelve families, from document and key-value stores to graph, time-series, vector, search, NewSQL, and multi-model engines.

This kind of breadth is exactly what distinguishes senior and principal engineers, who are trusted to make architecture decisions. Knowing that a fraud problem wants a graph, a semantic-search feature wants vectors, and a globally consistent ledger wants NewSQL is the judgment that shapes good systems, and it is what this program is built to develop.

Knowing the whole landscape, not just one or two engines, is what lets a senior engineer choose deliberately rather than by habit.

Twelve families, twelve prototypes

Rather than surveying databases in the abstract, the program grounds each family in a realistic enterprise scenario and has you build an end-to-end prototype. You build a retailer's catalog-and-orders service on a document store, a session store and rate limiter on a key-value engine, a bank's fraud-and-recommendation graph, an industrial sensor platform on a time-series database, and eight more, each a working system rather than a toy example.

Building a prototype in each family is what turns knowledge into judgment. By the end you have not just read about twelve kinds of database but stood one up, modeled real data in it, queried it, and operated it, which is what lets you reason confidently about which to choose when a real design decision arrives.

Building a prototype in each family is what turns database knowledge into the judgment to pick the right store for a workload.

Choosing the right store

The thread running through the program is polyglot persistence: the idea that a real system often uses several databases, each for what it does best, rather than forcing everything into one. You learn the trade-offs, the strengths, and the failure modes of each family, so you can compose a data architecture from the right pieces.

This is the capstone breadth of the databases stage. Alongside the deep single-engine programs on PostgreSQL, Oracle, SQL Server, and ClickHouse, this program gives you the wide view, the map of the whole database landscape, that a principal engineer draws on when designing an organization's data platform.

Polyglot persistence, composing a system from the right databases, is exactly the architecture thinking that principal engineers bring.

A worked example

See the method, not just the topic

A representative worked example from the program, so you can see the level of concreteness the curriculum works at.

A worked example: the same customer data, modeled for three different database families.
# The right model depends on the question you need to answer.

# Document store: the full customer profile in one record.
{ "id": "c-1042", "name": "Ada Lovelace",
  "addresses": [ {"city": "London", "type": "billing"} ],
  "preferences": { "currency": "GBP", "theme": "dark" } }

# Key-value store: a single fast preference lookup.
GET  pref:c-1042:currency   ->   "GBP"     # sub-millisecond

# Graph store: the relationships around the customer.
(c:Customer {id:"c-1042"})-[:OWNS]->(a:Account)
(a)-[:SENT]->(t:Transaction)-[:TO]->(other:Account)
# "Find accounts two hops from a flagged one" is a traversal here,
# but an expensive recursive join in a relational database.

# Same customer, three shapes. Knowing which shape each question
# wants, document, key-value, or graph, is the skill this program builds.
Curriculum · 12 families · 20 lessons each · 240 chapters

The full syllabus, family by family

Each of the 12 database families has its own twenty-lesson path in four modules, grounded in a distinct enterprise use case and building an end-to-end prototype. Expand any module to see its lessons.

Document Databases

20 lessons · MongoDB, Couchbase

Store data as flexible JSON or BSON documents rather than rows and columns, so each record carries a nested, evolving shape without a fixed schema.

Enterprise use case: a product-catalog and order service for a retailer, where every product has different attributes and orders embed line items, addresses, and status history in one document.

5 lessonsThe document model
  • 01Why documents, and when to choose themWhere a flexible, schema-light document model beats rows and columns.
  • 02Documents, collections, and databasesThe core building blocks of a document store.
  • 03JSON and BSON, and data typesHow documents are represented and typed.
  • 04Setting up the catalog projectStand up the environment and the retailer scenario you will build.
  • 05Modeling the first product documentDesign a product as a nested document.
5 lessonsModeling and querying
  • 06Embedding versus referencingThe central document-modeling decision and its trade-offs.
  • 07CRUD operationsCreate, read, update, and delete documents.
  • 08Query operators and filteringExpress real queries over document fields.
  • 09Indexing documentsIndex nested fields for fast lookups.
  • 10Modeling orders with embedded itemsDesign the order document with line items and history.
5 lessonsAggregation and analytics
  • 11The aggregation pipelineTransform and summarize documents in stages.
  • 12Grouping and computing metricsProduce sales and catalog analytics.
  • 13Joining collectionsCombine catalog and order data for reporting.
  • 14Building the reporting layerAssemble the analytics the retailer needs.
  • 15Optimizing aggregation performanceMake the pipeline fast at scale.
5 lessonsScale, operations, and the prototype
  • 16Replication and replica setsKeep the service available through failures.
  • 17Sharding for scaleDistribute documents across a cluster.
  • 18Transactions and consistencyWhen and how documents support transactions.
  • 19Securing and operating the storeAccess control, backups, and monitoring.
  • 20Shipping the catalog-and-orders serviceComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a working catalog-and-orders API on a document store, with nested documents, indexes, an aggregation pipeline for reporting, and a sharded, replicated deployment.

Key-Value Databases

20 lessons · Redis, Amazon DynamoDB

Store data as simple key-value pairs for extremely fast reads and writes, trading rich query power for raw speed and predictable low latency.

Enterprise use case: a session store and rate limiter for a high-traffic web platform, where millions of lookups per second must return in well under a millisecond.

5 lessonsThe key-value model
  • 01Why key-value, and its latency profileWhere raw-speed lookups matter more than query power.
  • 02Keys, values, and namespacesThe simple structure behind the speed.
  • 03Values and data structuresStrings, hashes, lists, sets, and sorted sets.
  • 04Setting up the platform projectStand up the environment and the high-traffic scenario.
  • 05First reads and writesBasic get and set at speed.
5 lessonsAccess patterns
  • 06Designing keysKey schemes that spread load and read fast.
  • 07Expiry and evictionTime-to-live and memory policies.
  • 08Caching patternsCache-aside, write-through, and their trade-offs.
  • 09Building the session storeModel sessions as keyed values with expiry.
  • 10Atomic operations and countersSafe increments for shared state.
5 lessonsBuilding the rate limiter
  • 11Rate-limiting algorithmsToken bucket, sliding window, and fixed window.
  • 12Implementing a counter-based limiterEnforce limits with atomic counters.
  • 13Avoiding hot keysSpread load to prevent bottlenecks.
  • 14Testing under loadVerify latency and correctness at volume.
  • 15Integrating the limiter into the appWire it into the request path.
5 lessonsPersistence, scale, and the prototype
  • 16Persistence optionsSnapshots and append-only logs for durability.
  • 17Replication and high availabilitySurvive node failures without downtime.
  • 18Partitioning and clusteringScale beyond one node.
  • 19Monitoring latency and throughputKeep the service fast and healthy.
  • 20Shipping the session-store and limiterComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a session store and rate limiter serving sub-millisecond lookups, with sound key design, expiry, persistence, and a replicated, highly available setup.

Wide-Column Databases

20 lessons · Apache Cassandra, Apache HBase

Organize data into rows with dynamic, wide sets of columns, optimized for writing and reading enormous volumes across a distributed cluster with no single point of failure.

Enterprise use case: a time-ordered event and messaging store for a large consumer app, ingesting billions of writes per day across many data centers with always-on availability.

5 lessonsThe wide-column model
  • 01Why wide-column, and its scale storyWhere always-on, write-heavy scale is the requirement.
  • 02Keyspaces, tables, and columnsThe wide-column structure.
  • 03The distributed, masterless designHow the cluster avoids a single point of failure.
  • 04Setting up the messaging projectStand up the environment and the consumer-app scenario.
  • 05Query-first thinkingModel tables around the queries you must serve.
5 lessonsModeling for the cluster
  • 06Partition keysHow data is distributed across the ring.
  • 07Clustering columns and orderingSort data within a partition.
  • 08Denormalization and table-per-queryDesign tables around access patterns.
  • 09Modeling the event streamDesign the time-ordered event table.
  • 10Modeling the message storeDesign the messaging tables query-first.
5 lessonsConsistency and the write path
  • 11Replication across data centersPlace replicas for durability and locality.
  • 12Tunable consistencyChoose consistency per operation.
  • 13The write path and commit logHow writes are made durable and fast.
  • 14The read path and compactionHow reads assemble data and stay efficient.
  • 15Handling high write volumeSustain billions of writes per day.
5 lessonsOperations, scale, and the prototype
  • 16Cluster topology and nodesDesign the ring and node roles.
  • 17Adding and removing nodesScale the cluster without downtime.
  • 18Monitoring and repairKeep replicas consistent and healthy.
  • 19Multi-data-center operationsRun across regions reliably.
  • 20Shipping the event-and-messaging storeComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a distributed event and messaging store modeled query-first, with a partitioning and clustering design, tunable consistency, and a multi-node cluster handling high write volume.

Graph Databases

20 lessons · Neo4j, Amazon Neptune

Store entities as nodes and relationships as edges, making it natural and fast to traverse deep, interconnected relationships that would be costly joins in a relational database.

Enterprise use case: a fraud-detection and recommendation graph for a bank, linking customers, accounts, devices, and transactions to surface rings and suspicious patterns in real time.

5 lessonsThe graph model
  • 01Why graphs, and where they winWhen relationships are the data.
  • 02Nodes, edges, and propertiesThe property-graph building blocks.
  • 03Graph versus relational joinsWhy traversals beat deep joins.
  • 04Setting up the fraud projectStand up the environment and the bank scenario.
  • 05Modeling the first entitiesModel customers, accounts, and devices.
5 lessonsQuerying the graph
  • 06A graph query languageExpress queries over nodes and edges.
  • 07Pattern matchingFind structures in the graph.
  • 08Traversals and variable-length pathsWalk relationships to any depth.
  • 09Modeling transactions as edgesConnect the money-movement graph.
  • 10Querying suspicious patternsWrite the fraud-signal queries.
5 lessonsGraph algorithms
  • 11Pathfinding and shortest pathsConnect entities through the graph.
  • 12Centrality and influenceFind the important nodes.
  • 13Community detectionSurface rings and clusters.
  • 14Similarity for recommendationsRecommend from graph structure.
  • 15Building the recommendation layerAssemble recommendations from the graph.
5 lessonsScale, real-time, and the prototype
  • 16Indexing and query performanceMake traversals fast.
  • 17Scaling large graphsHandle graphs that outgrow one machine.
  • 18Real-time fraud scoringScore transactions as they arrive.
  • 19Operating the graph storeBackups, monitoring, and access control.
  • 20Shipping the fraud-and-recommendation graphComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a fraud-detection and recommendation graph modeling customers, accounts, and transactions, running pattern-matching and pathfinding queries to surface suspicious rings.

Time-Series Databases

20 lessons · InfluxDB, TimescaleDB

Optimize for timestamped measurements written in order and queried over time windows, with efficient storage, retention, and downsampling of high-frequency data.

Enterprise use case: an industrial sensor and metrics platform for a manufacturer, ingesting readings from thousands of machines and serving live dashboards and alerts.

5 lessonsThe time-series model
  • 01Why time-series, and its workloadOrdered, timestamped, append-heavy data.
  • 02Measurements, tags, and fieldsThe time-series data model.
  • 03Storage and compression for time dataHow timestamped data is stored efficiently.
  • 04Setting up the sensor projectStand up the environment and the manufacturing scenario.
  • 05Writing the first measurementsIngest timestamped readings.
5 lessonsIngesting at scale
  • 06High-frequency ingestionTake in readings from thousands of machines.
  • 07Batching and write efficiencySustain high write rates.
  • 08Handling out-of-order and late dataCope with delayed readings.
  • 09Modeling the sensor fleetStructure tags for many machines.
  • 10Validating incoming dataCatch bad or missing readings.
5 lessonsQuerying over time
  • 11Time-window queriesAggregate over intervals.
  • 12Downsampling and rollupsSummarize high-frequency data.
  • 13Continuous aggregatesMaintain rollups automatically.
  • 14Retention policiesAge out raw data on a schedule.
  • 15Building the metrics queriesProduce the metrics the plant needs.
5 lessonsDashboards, alerts, and the prototype
  • 16Connecting a dashboard toolVisualize live metrics.
  • 17Building live dashboardsShow machine health in real time.
  • 18Threshold and anomaly alertsAlert when readings go wrong.
  • 19Scaling and operating the platformKeep ingestion and queries healthy.
  • 20Shipping the sensor-and-metrics platformComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a sensor and metrics platform ingesting high-frequency readings, with time-window aggregations, retention and downsampling, and live dashboards with alerting.

Object-Oriented Databases

20 lessons · ObjectDB, db4o

Persist application objects directly, preserving their structure and relationships without an object-relational mapping layer, so complex object graphs are stored and retrieved as-is.

Enterprise use case: a CAD and engineering-model store for a design firm, where deeply nested object structures must be saved and reloaded with full fidelity and no mapping overhead.

5 lessonsThe object database model
  • 01Why object databases existRemoving the object-relational mismatch.
  • 02Objects, classes, and persistenceHow objects become stored data.
  • 03The impedance mismatch problemWhy mapping to tables is costly for object graphs.
  • 04Setting up the engineering projectStand up the environment and the design-firm scenario.
  • 05Persisting the first objectsStore and retrieve a simple object.
5 lessonsStoring object graphs
  • 06Relationships between objectsPersist references and collections.
  • 07Deeply nested structuresStore complex engineering models.
  • 08Identity and equalityHow stored objects are identified.
  • 09Modeling the CAD domainDesign the engineering-model classes.
  • 10Round-tripping a modelSave and reload with full fidelity.
5 lessonsQuerying and transactions
  • 11Querying objects directlyFind objects without SQL.
  • 12Navigating object relationshipsTraverse the stored graph.
  • 13Transactions and the object lifecycleCommit, roll back, and manage state.
  • 14Concurrency and lockingCoordinate concurrent access.
  • 15Versioning stored objectsEvolve classes over time.
5 lessonsFit, operations, and the prototype
  • 16Performance characteristicsWhere object stores are fast and slow.
  • 17When object databases fitChoosing them versus the alternatives.
  • 18Backups and operationsKeep the object store safe.
  • 19Migration considerationsMove data in and out.
  • 20Shipping the engineering-model storeComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: an application that persists and reloads complex nested object graphs directly, with object queries, transactions, and a demonstration of full-fidelity round-tripping.

Columnar (Analytical) Databases

20 lessons · ClickHouse, Amazon Redshift, Snowflake

Store data by column rather than by row, so analytical queries scan only the columns they need and compress heavily, delivering fast aggregations over huge datasets.

Enterprise use case: a business-intelligence warehouse for a retailer, aggregating billions of sales rows into sub-second dashboards across products, regions, and time.

5 lessonsColumnar foundations
  • 01Why columnar, and where it winsScan-light analytics over huge datasets.
  • 02Row versus column storageHow layout changes performance.
  • 03Compression and encodingWhy columns compress so well.
  • 04Setting up the warehouse projectStand up the environment and the retailer scenario.
  • 05Loading the first analytical dataGet sales data into the warehouse.
5 lessonsModeling for analytics
  • 06Sort keys and data layoutOrder data for scan efficiency.
  • 07Dimensional modelingFacts and dimensions for BI.
  • 08Partitioning large tablesPrune data the query does not need.
  • 09Modeling the sales schemaDesign the retailer's analytical model.
  • 10Loading at scaleIngest billions of rows efficiently.
5 lessonsFast aggregation
  • 11Aggregations and roll-upsSummarize across products and regions.
  • 12Materialized viewsPre-compute results for speed.
  • 13Query optimizationMake dashboard queries sub-second.
  • 14Building the dashboard queriesProduce the retailer's BI queries.
  • 15Caching and concurrencyServe many dashboard users at once.
5 lessonsCost, operations, and the prototype
  • 16Performance tuningSqueeze out more speed.
  • 17Cost controlKeep analytics affordable at scale.
  • 18Operating the warehouseMonitoring, loading, and maintenance.
  • 19Connecting a BI toolSurface the warehouse in dashboards.
  • 20Shipping the BI warehouseComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a BI warehouse modeling sales data for fast aggregation, with a tuned schema, materialized roll-ups, and sub-second dashboard queries. This family is also covered in depth by the ClickHouse, Snowflake, and cloud-warehouse programs in this track.

NewSQL Databases

20 lessons · CockroachDB, Google Cloud Spanner

Combine the familiar relational model and strong transactional guarantees with the horizontal, distributed scalability usually associated with NoSQL systems.

Enterprise use case: a globally distributed ledger for a payments company, requiring strongly consistent transactions across regions without giving up SQL or ACID.

5 lessonsThe NewSQL model
  • 01Why NewSQL existsSQL and ACID at horizontal scale.
  • 02Distributed SQL versus NoSQLWhat NewSQL keeps and what it adds.
  • 03The relational model, distributedTables spread across a cluster.
  • 04Setting up the ledger projectStand up the environment and the payments scenario.
  • 05First distributed tablesCreate tables that span nodes.
5 lessonsDistributed transactions
  • 06Strong consistency across nodesHow NewSQL keeps data correct.
  • 07Distributed transaction protocolsCommitting across the cluster.
  • 08Isolation and correctnessSerializable behavior at scale.
  • 09Modeling the ledger schemaDesign the payments ledger.
  • 10Implementing money movementTransactional debits and credits.
5 lessonsData distribution
  • 11Ranges, shards, and rebalancingHow data spreads and moves.
  • 12Data locality and placementKeep data near its users.
  • 13Global tables and multi-regionDesign for many regions.
  • 14Handling region failuresStay available when a region drops.
  • 15Modeling multi-region ledgersPlace ledger data by region.
5 lessonsOperations, scale, and the prototype
  • 16Deploying a clusterStand up a distributed SQL cluster.
  • 17Scaling outAdd capacity by adding nodes.
  • 18Monitoring and resilienceKeep the cluster healthy.
  • 19Backups and disaster recoveryProtect the ledger.
  • 20Shipping the distributed ledgerComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a strongly consistent, multi-region ledger on a distributed SQL engine, with distributed transactions, region-aware data placement, and a resilient cluster.

In-Memory Databases

20 lessons · SAP HANA, Redis

Keep data primarily in RAM rather than on disk, delivering ultra-low latency for both transactions and analytics where speed matters more than storage cost.

Enterprise use case: a real-time pricing and risk engine for a trading desk, recomputing positions and exposure in memory as market data streams in.

5 lessonsThe in-memory model
  • 01Why in-memory, and its latency edgeWhen RAM speed is the requirement.
  • 02Memory versus disk data structuresHow in-memory storage differs.
  • 03The cost and capacity trade-offBalancing speed against memory size.
  • 04Setting up the pricing projectStand up the environment and the trading scenario.
  • 05First in-memory reads and writesWork with data at memory speed.
5 lessonsIn-memory processing
  • 06In-memory transactionsFast, consistent updates.
  • 07In-memory analyticsCompute over data without disk.
  • 08Streaming inputTake in market data as it arrives.
  • 09Modeling positions and exposureRepresent the risk state in memory.
  • 10Recomputing on the flyUpdate exposure as prices move.
5 lessonsDurability and capacity
  • 11Persistence for in-memory dataSnapshots and logs for durability.
  • 12Recovery after restartRebuild memory state safely.
  • 13Memory managementKeep within capacity.
  • 14Capacity planningSize memory for the workload.
  • 15Eviction and tieringHandle data larger than RAM.
5 lessonsAvailability and the prototype
  • 16Replication for in-memory storesKeep a hot standby.
  • 17High availability and failoverSurvive a node loss.
  • 18Monitoring latencyConfirm the speed target holds.
  • 19Operating the engineRun it reliably on the desk.
  • 20Shipping the pricing-and-risk engineComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a real-time pricing and risk engine holding working data in memory, recomputing exposure on streaming input, with a persistence and high-availability strategy.

Vector Databases

20 lessons · Milvus, Pinecone, Weaviate

Store high-dimensional embedding vectors and search them by similarity, powering semantic search, recommendations, and retrieval-augmented generation for AI applications.

Enterprise use case: a semantic search and retrieval layer for a company knowledge base, letting an AI assistant answer questions grounded in the organization's own documents.

5 lessonsVectors and embeddings
  • 01Why vector databases, and where they fitSimilarity search for AI.
  • 02Embeddings and vector spaceHow meaning becomes a vector.
  • 03Distance and similarity metricsCosine, dot product, and Euclidean.
  • 04Setting up the knowledge-base projectStand up the environment and the enterprise scenario.
  • 05Storing the first vectorsInsert and inspect embeddings.
5 lessonsIndexing and search
  • 06Approximate nearest neighborFast similarity at scale.
  • 07Index types and trade-offsSpeed versus recall.
  • 08Embedding documentsTurn the knowledge base into vectors.
  • 09Similarity queriesRetrieve the most relevant content.
  • 10Filtering with metadataCombine vectors with structured filters.
5 lessonsRetrieval-augmented generation
  • 11The RAG patternGrounding an AI answer in retrieved text.
  • 12Chunking and preparing documentsSplit content for retrieval.
  • 13Building the retrieval stepFetch context for a question.
  • 14Wiring retrieval into the assistantFeed context to the model.
  • 15Evaluating answer qualityMeasure and improve grounding.
5 lessonsScale, operations, and the prototype
  • 16Scaling vector searchHandle large document sets.
  • 17Tuning recall and latencyBalance quality and speed.
  • 18Updating and re-embeddingKeep the index current.
  • 19Operating the vector storeMonitoring and maintenance.
  • 20Shipping the semantic-search assistantComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a semantic-search layer over a document set, embedding content, indexing it for similarity search, and wiring it into a retrieval-augmented AI assistant.

Search Databases

20 lessons · Elasticsearch, OpenSearch

Index text for fast full-text search, ranking, filtering, and aggregation, so applications can search large document and log collections with relevance scoring and near-real-time results.

Enterprise use case: a product search and log-analytics platform for an online store, powering typo-tolerant product search and real-time operational dashboards over application logs.

5 lessonsSearch foundations
  • 01Why search engines, and where they fitFull-text search and relevance at scale.
  • 02The inverted indexHow search finds documents fast.
  • 03Analyzers, tokens, and termsHow text becomes searchable.
  • 04Setting up the search projectStand up the environment and the online-store scenario.
  • 05Indexing the first documentsGet products into the index.
5 lessonsQuerying and relevance
  • 06Full-text queriesMatch and search across text.
  • 07Relevance scoringHow results are ranked.
  • 08Typo tolerance and fuzzy searchForgive misspellings.
  • 09Filters and faceted searchNarrow results by attributes.
  • 10Building product searchAssemble the store's search experience.
5 lessonsAggregations and log analytics
  • 11Aggregations and facetsSummarize and group search results.
  • 12Ingesting logsStream application logs into the index.
  • 13Time-based log queriesSearch and filter logs over time.
  • 14Building log dashboardsVisualize operational metrics.
  • 15Near-real-time analyticsQuery fresh data quickly.
5 lessonsScale, operations, and the prototype
  • 16Shards and replicasDistribute the index for scale and safety.
  • 17Cluster operationsRun the search cluster reliably.
  • 18Index lifecycle managementAge out and roll over indices.
  • 19Tuning relevance and performanceImprove both quality and speed.
  • 20Shipping the search-and-logs platformComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a search and log-analytics platform with an inverted index, relevance-ranked product search, faceted filtering, and near-real-time log dashboards.

Multi-Model Databases

20 lessons · ArangoDB, Azure Cosmos DB

Support several data models, document, graph, key-value, and more, within a single engine, so one system can serve varied workloads without stitching together many databases.

Enterprise use case: a unified customer-360 platform for an enterprise, combining document profiles, a relationship graph, and key-value preferences in one database.

5 lessonsThe multi-model idea
  • 01Why multi-model, and when it helpsOne engine for several data shapes.
  • 02The models it combinesDocument, graph, and key-value together.
  • 03One engine versus many databasesThe consolidation trade-off.
  • 04Setting up the customer-360 projectStand up the environment and the enterprise scenario.
  • 05Choosing a model per workloadMatch each need to a model.
5 lessonsDocuments and key-value
  • 06Document profilesStore customer profiles as documents.
  • 07Key-value preferencesFast preference lookups.
  • 08Modeling the customer profileDesign the profile documents.
  • 09Querying documents and keysRetrieve profiles and preferences.
  • 10Indexing across modelsMake cross-model access fast.
5 lessonsThe relationship graph
  • 11Graph relationshipsModel connections between customers.
  • 12Traversing the customer graphWalk relationships for insight.
  • 13Combining graph with documentsEnrich profiles with relationships.
  • 14Building the unified viewAssemble the customer-360 record.
  • 15Cross-model queriesQuery documents, graph, and keys together.
5 lessonsDesign, trade-offs, and the prototype
  • 16Designing a unified platformArchitect the customer-360 store.
  • 17Consistency across modelsKeep the unified view coherent.
  • 18Trade-offs versus specialized storesWhen one engine wins, and when it does not.
  • 19Operating a multi-model storeRun it reliably.
  • 20Shipping the customer-360 platformComplete and demonstrate the end-to-end prototype.

Prototype built across the 20 lessons: a customer-360 platform using document, graph, and key-value models in a single engine, queried together, with a discussion of when this beats specialized stores.

How the program is taught

The program is hands-on and project-driven: you work with twelve database families, each with an end-to-end prototype through real labs rather than watching from a distance, and it builds toward a capstone you can keep and show. Every concept is applied, because platform skills are built by doing, not by reading about them.

It is structured so a motivated learner can start where they are and build steadily, with worked examples and code throughout. The through-line is always real, production-shaped work, so at every stage you are learning the platform the way practitioners actually use it.

Prerequisites and pace

SQL and the data-engineering foundation help, and the single-engine database programs complement it. No prior exposure to the specialized families is assumed. The pace builds from foundations to a capstone, and the most effective approach is to complete each lab rather than skim it, since the labs accumulate into the project.

For someone working toward the senior end of this track, consistency matters more than speed: steady progress through the material, and through the capstone, is what builds durable capability and a portfolio that demonstrates it.

What makes this program different

It goes broad rather than deep, teaching the whole database landscape and, crucially, when to reach for each family, which is the architecture judgment senior roles depend on. That focus is what turns knowledge of a platform into the ability to build and operate real systems on it.

The other distinction is the orientation toward the whole journey. Every program in this track is designed to fit with the others and to build toward the senior technical-leadership destination, so this one is taught as a step on that path rather than an isolated course.

Learning outcomes

What you will be able to do

  • Understand twelve database families and their trade-offs
  • Match the right database to a given workload
  • Build an end-to-end prototype in each family
  • Design polyglot-persistence architectures
  • Bring database breadth to senior platform decisions
Who it is for

Who should take it

  • Engineers who want the full database landscape
  • Data and platform engineers choosing the right store
  • Architects designing polyglot-persistence systems
  • Anyone growing toward senior data-platform roles
Where Specialized & Multi-Model Databases can leadThis programopens roles inData Platform EngineerData / Solutions ArchitectBackend / Data EngineerDatabase Engineertoward Principal Cloud & Data Platforms

Common questions

Does this replace the single-engine programs? No, it complements them. The PostgreSQL, Oracle, SQL Server, and ClickHouse programs go deep on one engine each; this one goes broad across twelve families so you can choose well.

Do I build something in each family? Yes. Each of the twelve families has a full twenty-lesson path that builds an end-to-end prototype grounded in a distinct enterprise use case, so you finish with twelve working systems.

Where it leads, toward Principal

In the near term, this program opens Data Platform Engineer and Architect roles, and toward the senior and principal positions that own database and architecture decisions. The capstone is concrete evidence of that capability, which matters more than any list of topics studied.

In the longer term, it is one rung on the ladder toward Principal Engineer and Director of Cloud and Data Platforms. That destination is reached through breadth across the whole stack plus the architecture, operations, and leadership judgment the senior programs emphasize, and this program contributes a genuine, in-demand piece of that breadth.

How it fits the journey

This program is the breadth capstone of the databases stage. It rests on the foundations before it and connects to the programs around it, so taking it in sequence builds cumulative command rather than isolated knowledge.

Because every program is also complete in itself, you can enter here if this is exactly the platform your goals require, and still get a whole, finished program. The sequence is a guide, not a gate, all the way up to the Principal and Director destination.

The project

What you build and keep

Across twelve database families you build twelve end-to-end prototypes, each grounded in a distinct enterprise use case, from a retailer's catalog service and a bank's fraud graph to a sensor platform, a distributed ledger, a semantic-search assistant, and a customer-360 store, so you learn not just how each database works but exactly when to reach for it.

Format: Self-paced with hands-on labs; twelve families, twenty lessons each, twelve prototypes.

Corporate training

Run this program for your team

Every program can be delivered as a private, tailored cohort for your organization, aligned to your systems, policies, and career frameworks.

Scope a corporate cohort
FAQ

Frequently asked questions

What is the Specialized & Multi-Model Databases program?

Go beyond relational and columnar engines: twelve database families, from document, key-value, graph, and time-series to vector, search, NewSQL, and multi-model, each with a distinct enterprise use case and an end-to-end prototype you build.

Who is this program for?

It suits engineers who want the full database landscape, along with others described on this page.

How is it delivered?

Self-paced with hands-on labs; twelve families, twenty lessons each, twelve prototypes.

Is there a project or capstone?

Across twelve database families you build twelve end-to-end prototypes, each grounded in a distinct enterprise use case, from a retailer's catalog service and a bank's fraud graph to a sensor platform, a distributed ledger, a semantic-search assistant, and a customer-360 store, so you learn not just how each database works but exactly when to reach for it.

How does this fit the wider journey?

This program closes the databases stage by going broad rather than deep, complementing the single-engine programs. The ability to choose the right database for a workload is a hallmark of the senior and principal roles the whole track builds toward.

Can my organization run this as a private cohort?

Yes. Every program can be delivered as a tailored corporate cohort. Contact us to scope it.