Season 5 Ep 6 — If Ep 5 was "the language of metrics," Ep 6 is "the specialized stores that AI and ML demand". They started out as separate categories, and in 2025 they are converging to a remarkable degree.
- Prologue — "The DB Landscape Got Redrawn Because of AI"
- Chapter 1 · Feature Store — The Language of ML
- Chapter 2 · Vector DB — The Language of AI
- Chapter 3 · Graph DB — The Language of Relationships
- Chapter 4 · Time-Series DB — The Language of Operations
- Chapter 5 · The Arrival of the "Unified DB"
- Chapter 6 · The Shock AI Dealt to the DB Landscape
- Chapter 7 · The Selection Guide
- Chapter 8 · Korean Companies in Practice
- Chapter 9 · Three Case Studies
- Chapter 10 · Ten Antipatterns
- 10.1 "A Vector DB in Every Product"
- 10.2 Using a Graph DB as an OLTP Replacement
- 10.3 Piling Time-Series Data Straight into OLTP
- 10.4 Running Five ML Models Without a Feature Store
- 10.5 No Online-Offline Synchronization
- 10.6 No Vector Index Tuning
- 10.7 Ignoring Hybrid Search
- 10.8 Handing the LLM Raw Documents Without GraphRAG
- 10.9 Adopting Every Specialized DB Up Front
- 10.10 Scattered Data Governance
- Chapter 11 · Checklist — 12 Items for Adopting a Specialized DB
- Chapter 12 · Next Post Preview — Season 5 Ep 7: "Data Governance·Lineage·PII"
Prologue — "The DB Landscape Got Redrawn Because of AI"
Between 2015 and 2020 the DB categories were crisp:
- OLTP: Postgres/MySQL
- OLAP: warehouse
- NoSQL: Mongo/Cassandra/Redis
- Time series: InfluxDB
After the 2022 LLM boom, vector DBs exploded — and in 2024–2025 the movement reversed:
- Postgres + pgvector → the general-purpose DB swallowed vectors
- Lakehouse → absorbed features, vectors, and time series together
- Time-series DBs added vector support
- Graph DBs came back through AI recommendation and GraphRAG
The boundaries are blurring. This post organizes that chaos.
Chapter 1 · Feature Store — The Language of ML
1.1 Why You Need One
- When ML training and inference use different features, you get online-offline skew
- Every team recomputes its own features → duplication and inconsistency
- No reproducibility, no audit trail, no governance
1.2 The Two Tiers of a Feature Store
- Offline Store: batch training and backfill (Lakehouse/Iceberg/BigQuery)
- Online Store: low-latency inference (Redis/DynamoDB/Cassandra)
- Both tiers are generated from the same definition
1.3 The Main Tools
- Feast (open source): the most popular, driven by Tecton
- Tecton (commercial): real-time feature pipelines
- Hopsworks: an end-to-end ML platform
- Databricks Feature Store: Delta integration
- Vertex AI Feature Store: GCP
- SageMaker Feature Store: AWS
1.4 A Feast Example
from feast import Entity, FeatureView, Field
from feast.types import Float32
user = Entity(name='user', join_keys=['user_id'])
driver_stats = FeatureView(
name='user_stats',
entities=[user],
schema=[Field(name='avg_order_value', dtype=Float32)],
source=...
)
1.5 Preventing Online-Offline Skew
- Generate features on both sides with the same SQL/code
- Point-in-time correctness: training features must be the values as of that moment
- Materialization: periodic Offline → Online synchronization
- Data validation: detect distribution anomalies
1.6 The 2024–2025 Trend
- More and more Feature Stores built on top of Iceberg and Delta
- Combined with real-time feature pipelines (Flink/RisingWave)
- Attempts to manage LLM RAG context data through the Feature Store as well
Chapter 2 · Vector DB — The Language of AI
2.1 The 2022–2024 Explosion
- The LLM RAG craze pushed the vector DB category into the spotlight
- Pinecone's Series B, $100M (2023)
- Weaviate, Qdrant, Milvus, Chroma, LanceDB and many more appeared
2.2 The Major Vector DBs
| Name | Type | Characteristics |
|---|---|---|
| Pinecone | SaaS | Industry leader, easy to manage |
| Weaviate | Open + SaaS | Hybrid search, modules |
| Milvus | Open + SaaS | Large scale, commercialized by Zilliz |
| Qdrant | Open + SaaS | Rust, fast |
| Chroma | Open | Embedded, developer friendly |
| LanceDB | Open | File based, embedded |
| pgvector | Postgres extension | Integrated into a general-purpose DB |
| Vespa | Open | Yahoo origin, strong at ranking |
| Elasticsearch | Search + vector | Existing search plus vectors |
| Redis Vector | In memory | Ultra-low latency |
2.3 The Main Algorithms
- HNSW: the industry-standard approximate nearest neighbor search
- IVF: efficient at large scale
- ScaNN (Google): large scale plus accuracy
- DiskANN (Microsoft): SSD based, ultra-large capacity
2.4 Hybrid Search
- Dense (vector) combined with sparse (BM25)
- Settled in as the default standard in 2024–2025
- Weaviate, Vespa, Elastic, and OpenSearch all support it
2.5 The Counterattack of Postgres + pgvector
- pgvector improved explosively through 2023–2024
- HNSW indexes, metadata filtering, hybrid search
- "Do not stand up one more DB — do it in Postgres" became a common 2025 choice
2.6 Where It Gets Used
- Context retrieval for RAG
- Recommendation systems
- Image, video, and audio similarity
- Clustering and anomaly detection
Chapter 3 · Graph DB — The Language of Relationships
3.1 Why It Is Rising Again
- Knowledge-graph-based RAG (GraphRAG) took off in 2024
- Recommendation, fraud detection, supply chain analysis
- The pattern of LLMs making use of structured knowledge
3.2 The Major Graph DBs
- Neo4j: the industry leader, the Cypher language
- NebulaGraph: Chinese origin, large scale
- Dgraph: distributed GraphQL
- TigerGraph: high-performance analytics
- Amazon Neptune: managed on AWS
- ArangoDB: multi-model (document + graph)
- Apache AGE: Postgres extension (graph)
- Kuzu: embedded graph (recently getting attention)
3.3 Query Languages
- Cypher: the Neo4j standard, the most widely used
- Gremlin: Apache TinkerPop
- GQL: ISO standardization in progress
- GraphQL: adopted as an API language by Dgraph and others
3.4 GraphRAG
- Hand the LLM the relevant entities and relationships as a graph
- Strong on questions like "who are the key owners of the projects this person worked on?"
- Microsoft GraphRAG (2024), LlamaIndex KnowledgeGraph, and others
3.5 Where It Gets Used
- Fraud detection (transaction networks)
- Recommendation (user-item-attribute relationships)
- Knowledge graphs (corporate information, academia, healthcare)
- Supply chain, cybersecurity
3.6 Limits and Reality
- A graph DB usually owns "one part" of the picture
- Postgres/warehouse stays the main store; the graph handles a specific workload
- Lightweight options like Apache AGE and Kuzu have lowered the barrier to entry
Chapter 4 · Time-Series DB — The Language of Operations
4.1 The Categories
- Dedicated: InfluxDB, TimescaleDB, VictoriaMetrics, QuestDB
- Observability friendly: Prometheus, M3, Cortex, Mimir, Thanos
- Built into general-purpose engines: ClickHouse, BigQuery, and Snowflake can handle time series too
4.2 The Main Tools
- InfluxDB 3: a 2024 redesign on Parquet/Arrow
- TimescaleDB: a Postgres extension, the most general-purpose
- VictoriaMetrics: Prometheus compatible, extremely fast
- QuestDB: ultra-fast ingest, SQL
- Prometheus: the monitoring standard, long-term retention via Thanos/Cortex
- ClickHouse: logs, metrics, and traces unified
4.3 Where It Meets AI and ML
- Generating time-series features (the source for a Feature Store)
- Time-series anomaly detection and summarization with LLMs
- Combined with forecasting models (Prophet, Nixtla)
4.4 The 2024–2025 Trend
- OpenTelemetry unified the three signals (metric, log, trace)
- ClickHouse, SigNoz, and Grafana Cloud Loki/Mimir/Tempo became unified backends
- TimescaleDB absorbs the Postgres ecosystem and supports vectors too (pgvector)
4.5 Where It Gets Used
- APM and infrastructure monitoring
- IoT and sensor data
- Financial transaction timelines
- User behavior timelines
Chapter 5 · The Arrival of the "Unified DB"
5.1 The 2024–2025 Phenomenon
- Postgres + extensions: OLTP + vector + time series + graph (AGE)
- ClickHouse: OLAP + logs/metrics + vectors (expanded in 2024) + similarity
- MongoDB: document + Atlas Vector Search
- Elastic: search + vector + observability
- Snowflake/Databricks: warehouse + vector + ML + streaming
5.2 Why They Are Converging
- The cost of operating several DBs
- The burden of data replication and consistency
- Startups prefer to start with one
5.3 The Limits of Unification
- They cannot match the performance and feature depth of specialized engines (Pinecone, Neo4j, InfluxDB)
- At large scale you have to split them apart again
- "Single DB vs. multiple specialized DBs" is a balance struck per scale and workload
5.4 The 2025 Recommendation
- Early, under 10M records: a single DB (Postgres + extensions) is enough
- Mid-stage, 10M–1B: a unified DB plus a few dedicated ones
- Large scale, 1B+: specialized DBs split out per workload
Chapter 6 · The Shock AI Dealt to the DB Landscape
6.1 The Vector DB Explosion → Convergence
- 2022: the category is born
- 2023: dozens of vendors
- 2024: Postgres/ES/Mongo absorb it → specialized vector DBs focus on large scale and ultra-low latency
6.2 The Rediscovery of Graphs
- GraphRAG and LLM knowledge bases
- Enterprise data integration (knowledge graphs)
- Neo4j and Microsoft GraphRAG spreading
6.3 Time Series + LLMs
- Natural language querying over logs and metrics with an LLM
- LLM assistance for forecasting and anomaly detection
- OpenTelemetry + LLM observability platforms
6.4 The Expansion of the Feature Store
- From traditional ML features → managing LLM RAG context too
- Experiments with a combined vector + feature store
- Reusing the online-offline synchronization pattern
6.5 Beware of DB Sprawl
- Two to five DBs per product → a management burden
- The 2025 wisdom: balance "depth of specialization vs. simplicity of operations"
Chapter 7 · The Selection Guide
7.1 "When You Need a Dedicated Vector DB"
- 100M+ vectors, ultra-low latency required
- Complex metadata filtering plus hybrid search
- A dedicated ML team exists
→ Pinecone, Weaviate, Milvus, Qdrant
7.2 "Postgres + pgvector Is Enough"
- < 10 million vectors
- You want to use the existing Postgres stack
- Operational and audit convenience comes first
7.3 "When You Need a Graph DB"
- Relationships are the core business logic (fraud detection, recommendation)
- Recursive and path queries are frequent
- A large-scale knowledge graph
→ Neo4j, NebulaGraph, Neptune
7.4 "When You Need a Time-Series DB"
- Tens of thousands of metrics/logs per second
- Long-term retention plus aggregation queries
→ TimescaleDB (general purpose), VictoriaMetrics/ClickHouse (large scale)
7.5 "When You Need a Feature Store"
- Two or more ML models in production
- Ten or more features shared
- Training-inference skew problems showing up
→ Feast (lightweight), Tecton/Databricks (enterprise)
Chapter 8 · Korean Companies in Practice
8.1 Adoption Status
- Vector DB: through 2023–2024 most started on Pinecone/Weaviate; in 2025 migrations to pgvector and Elastic are rising
- Graph DB: traditionally used in finance (fraud detection) and telecom (networks), leaping again in the LLM era
- Time-series DB: APM and IoT center on InfluxDB/Prometheus
- Feature Store: Coupang, Karrot, Toss, and Naver have built their own
8.2 Network Separation and On-Prem Requirements
- Finance and public sector: self-operating open source (Milvus, Qdrant, Neo4j Community)
- On-prem vector DB deployment SI work is growing
- Korean embedding models (Solar, KoSimCSE, E5-Korean) combined with a local vector DB
8.3 Cost and Performance Tips
- Experiment with whether you can lower the embedding dimension (dimension reduction)
- Improve accuracy with dense + sparse hybrid
- Cold data in Parquet + Iceberg, hot data in the vector DB
8.4 Korean Participation in 2025
- Upstage Embedding / Solar → domestic embedding models spreading
- Samsung SDS, LG CNS, and Naver Cloud offering vector·graph·LLM bundles
- Startup demand for GraphRAG and on-prem vector DB builds
Chapter 9 · Three Case Studies
9.1 E-commerce Recommendation
- User·Item·Order graph: Neo4j
- Item embeddings: pgvector or Pinecone
- Real-time features: Feast + Redis
- Result: +20% accuracy on "products likely to be bought next"
9.2 Financial Fraud Detection
- Transaction graph: NebulaGraph
- User behavior time series: TimescaleDB
- Real-time rules plus ML scores: Feast + Flink
- Result: fewer false positives, shorter response time
9.3 An Enterprise AI Assistant (RAG)
- Document embeddings: Weaviate
- Internal knowledge graph: Neo4j + GraphRAG
- User permissions and metadata: Postgres
- The LLM is combined with the Semantic Layer
Chapter 10 · Ten Antipatterns
10.1 "A Vector DB in Every Product"
Overinvesting when pgvector would have done.
10.2 Using a Graph DB as an OLTP Replacement
It is a poor fit for transaction processing.
10.3 Piling Time-Series Data Straight into OLTP
Bloated tables, runaway queries.
10.4 Running Five ML Models Without a Feature Store
Duplicated feature computation and skew.
10.5 No Online-Offline Synchronization
A model that trained beautifully falls apart in production.
10.6 No Vector Index Tuning
Leaving HNSW/IVF at their defaults degrades performance.
10.7 Ignoring Hybrid Search
Dense-only is weak on keyword queries.
10.8 Handing the LLM Raw Documents Without GraphRAG
Accuracy drops on relational questions.
10.9 Adopting Every Specialized DB Up Front
Too much operational burden.
10.10 Scattered Data Governance
Separate PII and audit trails across five DBs, and consistency collapses.
Chapter 11 · Checklist — 12 Items for Adopting a Specialized DB
- Classify the workloads (ML features, vectors, graphs, time series)
- Decide single vs. specialized DB by scale
- Evaluate whether you need a Feature Store
- Benchmark vector index algorithms and parameters
- Decide whether to adopt hybrid search
- Write down the graph query patterns (Cypher/GQL)
- The time-series ingestion pipeline
- Detection and alerting for online-offline skew
- Unified security, permissions, and audit
- PII and encryption policy
- Cost forecasting and monitoring
- Operations, backup, and DR plan
Chapter 12 · Next Post Preview — Season 5 Ep 7: "Data Governance·Lineage·PII"
The more specialized DBs you accumulate, the harder governance gets. Ep 7 covers managing the entire path data flows along.
- The OpenLineage standard
- Collibra / Atlan / DataHub / Alation
- The governance layer of Unity Catalog / Polaris / Glue
- PII detection, masking, and tokenization
- Data subject rights under GDPR and Korea's Personal Information Protection Act
- Sensitive data classification
- Data contracts (an extension of Ep 4) and auditing
- Multi-cloud, multi-DB governance
- The governance reality at Korean companies
- Extending governance for the AI era
"If you do not manage your data, your data will manage your company." That is the theme of Ep 7.
See you in the next post.
Summary: The 2025 DB landscape is a phase of convergence after AI and ML shook it. For vector DBs, specialized vendors coexist with Postgres/ES/Mongo integration; graph DBs are rising again through GraphRAG and fraud detection; time-series DBs are merging with OpenTelemetry; and Feature Stores are fusing with Iceberg and real-time streaming. "Start with a single DB → specialize as you scale" is the dominant pattern, and what makes Korean companies distinctive is network separation, Korean embeddings, and self-operating Feast/Neo4j/Milvus. The next post sits on top of all of it: data governance · lineage · PII.