Kafka, streamed straight in.
Point Basalt at any topic. Records land in one ordered log with their offsets, then flow into typed views you can query in milliseconds.
Overview
How it works.
Basalt joins your cluster as a consumer group. Each partition is read in order, written to the log with its offset, and committed only after the write is durable in three zones.
Setup
Set it up in three steps.
01
Add the source
Run one command with your topic and auth method. Basalt reads the brokers from your workspace secrets and samples the first records to infer a schema.
# connect the payments topic over SASL/SCRAM basalt source add payments --kafka payments.v3 --sasl scram
✓ joined consumer group basalt-payments
✓ 12 partitions streaming · lag 0
02
Shape it with a view
Write plain SQL over the source. Basalt keeps the view current with every record and tracks lineage back to the topic, partition and offset.
CREATE MATERIALIZED VIEW revenue_by_min AS SELECT date_trunc('minute', ts) AS minute, currency, sum(amount) AS revenue, count(*) AS payments FROM payments WHERE status = 'captured' GROUP BY 1, 2;
03
Read it from anywhere
Every view is an endpoint the moment it exists. Call it over REST, connect with any Postgres client, or use the SDK from your app.
curl https://api.basalt.dev/v1/views/revenue_by_min?limit=5 \ -H "Authorization: Bearer $BASALT_TOKEN"
✓ 200 OK · 5 rows · served from eu-north-1 in 3.1 ms
Included
What you get.
01
Exactly-once
Offsets commit with the write. Restarts and rebalances never double-count a record.
02
Schema inference
JSON, Avro and Protobuf are typed on arrival. Registry subjects are picked up when present.
03
Back-pressure
Consumers slow down before your brokers do. Lag is visible per partition in the console.
04
Offset replay
Rewind to any offset or timestamp and rebuild a view without touching the cluster.
Related
