01
HTAP Engine
Hybrid transactional/analytical processing — operational writes serve real-time dashboards without ETL or read replicas.
Operational databaseGENEDATA / 01
One foundation.Every data workload.
Connect operational and analytical workloads without losing the relationship between a transaction and the insight it creates.
Shared context · Lineage · Governance
Connected
Your sources
Transactions
Documents
Time-series events
Connected intelligenceDatabase engine
Governance
Business impactApplications & analytics
Shared contextLineageGovernance
02
Multi-Modal
Relational, JSON, vector, and time-series data in one cluster. Query across modalities with a single SQL dialect.
03
Point-in-Time Recovery
Continuous backup with second-level recovery point objective. Restore any database to any timestamp in the last 35 days.
HTAP Topology
Transactional writes and analytical reads, one copy of the truth.
A row committed by your application is visible to an analytical query immediately, because both run against the same storage with different access paths. There is no replication lag to reason about and no nightly job to keep two systems agreeing with each other.
How It Works
Write once, read every way.
The engine keeps a row-oriented path for transactions and a column-oriented path for analytics over the same committed data, and picks between them per query.
Commit transactionally
Full ACID semantics with familiar SQL. Applications treat it as the operational database they already know.
Materialise both paths
Committed rows are maintained in row and columnar representations, so neither workload is served by a compromise layout.
Plan per query
The planner chooses the access path from the shape of the query — point lookups take the row path, aggregates take the column path.
Recover to any second
Continuous backup means recovery is a timestamp, not a nightly snapshot plus a stack of write-ahead logs.
Capabilities
Four stores' worth of capability, one cluster.
Each modality is a first-class access path rather than an extension bolted onto a relational core.
Relational
Standard SQL with ACID transactions, foreign keys, and the isolation levels your application already assumes.
Document / JSON
Schemaless documents queried with the same dialect, indexed on nested paths without a separate document store.
Vector search
Native embedding columns with approximate nearest-neighbour indexes, joinable against relational data in one query.
Time-series
Automatic downsampling, retention tiers, and interval functions for high-cardinality metric workloads.
Cross-modal joins
Join a vector similarity result to a relational customer table and a time-series metric in a single statement.
Point-in-time recovery
Sub-second RPO with restore to any timestamp in the retention window, tested by automated recovery drills.
In Practice
Who this is for.
Collapsing four stores into one changes different things for different teams.
Application Developer
Ship features without a second datastore
Add semantic search or a time-series metric to an existing service without provisioning, learning, and operating another database.
One connection string, one dialect, one set of transactions.
Data Analyst
Query production data that is actually current
Analytical queries read committed state directly, so a dashboard reflects the last few seconds rather than last night's load.
Real-time reporting without a replication pipeline.
Platform / SRE
Retire the sync jobs
Eliminate the ETL and CDC plumbing whose only job was keeping four independent stores approximately in agreement.
Fewer moving parts, fewer 3am consistency incidents.
What Changes
What changes when the stores collapse.
Running a specialised database per workload is defensible until you count the integration between them.
| Dimension | Before Genedata | With Genedata |
|---|---|---|
| Footprint | Separate relational, analytical, vector, and time-series clusters | One cluster serving all four access patterns |
| Freshness | Analytics lag production by a replication interval | Analytical queries read committed state directly |
| Consistency | Four stores that disagree during any sync failure | One committed copy, no reconciliation required |
| Cross-modal queries | Application-side joins across separate systems | A single SQL statement spanning modalities |
| Operations | Four upgrade cycles, four backup regimes, four on-calls | One cluster to patch, back up, and monitor |
SQL · JSON · Vector · TSModels
Batched commitWrite Path
B-tree · GIN · HNSWIndexing
Point-in-timeRecovery
The next step
One cluster. Every workload pattern.
Stop paying for Postgres + ClickHouse + Pinecone + InfluxDB and the engineers required to keep them in sync. Genedata Database collapses the operational footprint while delivering best-of-breed performance per workload.
FAQ
The database, answered.
What application and platform teams ask about collapsing four stores into one.
How is this different from a standard relational database?
It maintains row-oriented and column-oriented representations of the same committed data and picks between them per query. Point lookups take the row path, aggregates take the column path — which is why analytics can read production state directly without a replica.
Is analytical querying safe against production?
Yes. Analytical work runs on the columnar path with its own compute, so a large aggregate does not contend with transactional writes. Workload isolation is enforced rather than advisory.
What does multi-modal actually mean here?
Relational, JSON, vector, and time-series are first-class access paths on one engine rather than extensions bolted onto a relational core, and a single statement can join across all four.
What is the recovery story?
Continuous backup gives a sub-second recovery point objective, and restore targets a timestamp rather than a nightly snapshot plus a stack of write-ahead logs. Recovery drills are automated.
Can I migrate without rewriting my application?
Standard SQL with ACID semantics, foreign keys, and the isolation levels your application already assumes means most applications move with a connection-string change and a compatibility pass.
Related content
Architecture
Engine Architecture
Storage layout, the planner, and replication topology.
RunbookBackup and Restore
Point-in-time recovery procedures and drill automation.
GuideMigration Playbook
Moving from Postgres, ClickHouse, or a vector store.
RelatedCortex SQL
The analytics engine reading the same committed state.
Take the next step
Collapse four stores into one.
Walk your current topology through with an engineer and see what consolidates — or read the migration playbook first.