Everything you know, in one queryable place.

Atom is a per-tenant lakehouse that turns documents, structured data and external systems into a single surface your people, your applications and your agents can all query.

Talk to our team What it does

One lakehouse, many front doors #

Data work usually starts by moving data: extract it, reshape it, load it somewhere else, then discover the copy is a day old and the permissions did not come with it. Atom removes that step. Tables live as open columnar and vector datasets on storage you choose, and one engine reads them in place.

The hard part was never storage anyway, it is access: who can see which rows, whether the answer includes this morning's writes, and whether a question asked in English gets the same treatment as one written in SQL. So there is one engine and one governance path, and everything else is a door into it. Analysts connect over the PostgreSQL wire protocol, data tools pull columnar batches over Arrow Flight SQL, applications call REST, and agents ask in plain language.

The permission decision is identical whichever door the question came through.

What Atom does #

Four ideas carry the product. Everything else is detail.

One engine, four ways to ask #

Analytical SQL, hybrid search, plain language and graph traversal all plan through the same engine, so the tool a question arrives in never changes the answer.

Analytical SQL over the lakehouse
Keyword and semantic search, fused
Plain language, with citations

Query what you never migrated #

External databases register as native tables and work pushes down to them, so one query spans the lakehouse and the systems you cannot move.

PostgreSQL, MySQL and ODBC sources
Push-down to the source system
Never stale: hot writes union in

Any source becomes searchable #

Contract archives, scanned reports and shared drives arrive as structured, segmented, embedded data without a separate document platform.

Layout, table, figure and text recognition
Segments sized for retrieval
Embedded through your own models

Governance that does not depend on the door #

Row filters, column masks and deny decisions are evaluated on every read through one shared path, and every access lands in a redacted audit record.

One permission path on every interface
Redacted audit record of every access
Per-tenant datasets, not a tenant column

The same session, two questions #

Connect a standard PostgreSQL client and both of these run in it: keyword and semantic retrieval as a table function, and a join to a database nobody migrated.

hybrid search

-- alpha 0 is pure keyword, 1 is pure meaning, 0.5 fuses both.
SELECT clause_ref,
       effective_date,
       hybrid_score
  FROM hybrid_search('contracts.clauses', 'termination for convenience', 10, 0.5)
 ORDER BY hybrid_score DESC;

Search returns your table's own columns plus the three scores behind the ranking, so you can see why a row placed where it did.

federated join

-- 'erp' is an external database registered as native tables.
SELECT c.customer_id,
       c.signed_at,
       erp.accounts.owner
  FROM contracts AS c
  JOIN erp.accounts USING (customer_id)
 WHERE c.signed_at >= now() - interval '90 days'
 ORDER BY c.signed_at DESC;

Work pushes down into the external system where it can, so nothing is copied and the answer is never a day old.

In more detail #

The full capability surface, grouped by the job it does.

Open lakehouse storage

Multi-tenant, versioned and self-maintaining, with no separate warehouse to load.

Open datasets: Every table is an open columnar and vector dataset, versioned and queryable in place rather than locked inside a proprietary warehouse.
Storage you choose: Datasets rest on pluggable, tenant-scoped object storage: the platform's sovereign store by default, or your own S3-compatible backend.
Hot and cold tiers: Fresh writes buffer in the transactional database and flush in the background, behind a visibility barrier that keeps readers on consistent revisions. Scheduled compaction keeps queries fast without taking a dataset offline.
Live change feed: Every change is published as a stream, so search indexes, live queries and downstream consumers stay current in real time.

Query and federation

One SQL engine over the lakehouse and the systems around it, streaming results of any size.

SQL over the lakehouse: Analytical SQL planned and executed directly against your datasets, with no copy into a separate engine first.
Always the latest write: Queries transparently union not-yet-flushed rows with durable data, so results reflect the newest committed state.
Federated sources: Register external PostgreSQL, MySQL and ODBC databases as native tables and push work down to them, so a single query can span the lakehouse and the systems you already run.
Streaming results: Results stream back as Arrow record batches under a strict terminal contract, so arbitrarily large answers never buffer in memory.

Hybrid retrieval

Keyword precision and semantic recall fused into one ranked result. The backbone behind agent memory, chat grounding and in-app search.

Hybrid ranking: Keyword and vector search combined by rank fusion into a single relevance-ordered result, tunable from pure keyword to pure semantic.
Semantic and exact-term indexes: Native vector indexes for nearest-neighbour search, and inverted indexes for keyword scoring and exact-term matching, so precise queries stay precise.
Indexes that keep up: Tenant-scoped index builds come online automatically as data lands, with hot rows folded into results until the next build completes.

Ingestion and understanding

Any source into searchable data, plus a continuously inferred picture of what that data means.

Document intelligence: Layout, table, figure and optical character recognition for documents, plus office and spreadsheet formats and images, extracting structured text from unstructured files.
Segmentation and embedding: Extracted content is split into overlapping, de-duplicated segments sized for retrieval, then embedded through your own models and indexed automatically.
Connected sources and firehose: Incremental sync of files and mail from the systems your organisation already uses, alongside a staged, manifest-committed path for very high-bandwidth event ingestion.
Schema graph and relationships: A continuously inferred map of tables, columns, sensitivity and relationships that the language planner and the graph endpoint both reason over, with focusable diagrams that explain a dataset at a glance.

Machine learning on your data

On-demand models trained against the same federated data, without exporting anything.

Forecasting: Time-series forecasting trained on demand over federated tenant data, using gradient-boosted and statistical models, versioned and persisted to tenant-scoped storage.
Anomaly detection: Outlier detection for monitoring and data quality, with several methods to suit different shapes of signal.
Similarity: Vector and structural record similarity for matching, de-duplication and recommendation.

Governance and tenancy

One fail-closed control model, applied identically no matter which door a query came through.

Permission filtering: Row filters, column masks and deny decisions evaluated on every read through one shared path, so REST, columnar, wire-protocol, language and graph queries all enforce the same rules.
Query safety: Read-only by default, with mandatory limits and bounded cost on every query, whether a person wrote it or a model generated it.
Audit ledger: A canonical, redacted record of every data access, correlated to the identity and the query behind it.
Per-tenant by construction: Storage, indexes and models are scoped to a tenant, and heavy tenants get their own search and database capacity, composed automatically rather than provisioned by hand.

What teams do with it #

Three patterns the lakehouse is shaped around.

Ground your assistants

Point a conversational agent at hybrid search over your own corpus and get answers with citations, retrieved under the asking user's permissions rather than a service account's.

Self-service analytics

Let analysts connect the tool they already use over the PostgreSQL wire protocol, and let everyone else ask in plain language and get safe SQL underneath.

Query across the estate

Join the lakehouse to the operational databases you cannot migrate, in one query, without building a pipeline to move them first.

How you connect #

One query engine behind several protocols, so existing tools, drivers and clients work unchanged and every one of them gets the same governance.

REST and HTTP
Arrow Flight SQL
PostgreSQL wire protocol
Graph queries
Model tools

What each interface gives you

REST and HTTP: The interface applications and user interfaces query through, including live subscriptions over server-sent events.
Arrow Flight SQL: High-throughput columnar access for data tools and notebooks that want record batches rather than rows.
PostgreSQL wire protocol: Standard PostgreSQL clients, drivers and analytics tools connect to the lakehouse as if it were PostgreSQL.
Graph queries: A read-only graph endpoint speaking ISO GQL and compatible with Bolt clients, for querying tabular data as a connected graph.
Model tools: Search, retrieval and query are exposed to agents as governed tools, each call subject to the same capability check as any other caller.

Bring us a data problem

Tell us what your estate looks like, where the documents live and which questions nobody can currently answer. We will show you how Atom would answer them.

Talk to our team