ETL that stops being a project.
Point Databasin at a source, choose how the data should land, and the data pipeline builds itself: schema mapped, schedule set, changes tracked, arriving as Apache Iceberg tables in storage you own.
ETL or ELT?
Both, and the distinction matters less here than it used to. Data lands in the lakehouse first and is shaped there, which is ELT in the usual sense. But heavy transformation runs on Spark against the same tables, and SQL, dbt and notebooks all run as scheduled tasks. You are not picking an architecture. You are picking where a given transform is cheapest to run.
Five ways data can land
Set per table rather than per pipeline, so one data pipeline can refresh a small reference table in full while loading a large fact table incrementally. The mode decides what a run does to the target.
| Mode | What a run does |
|---|---|
| Snapshot | Full refresh every run. Simple, and right for small or reference tables. |
| Delta | Incremental upsert against a watermark, so only what changed moves. |
| Historical | Append only. Nothing is overwritten, so the history stays queryable. |
| CDC | Change data capture, for sources that can tell you what changed. |
| Stored procedure | The source defines its own extract and Databasin runs it. |
What a native connector does for you
75+ connectors, of which 30 are native. For those 30 you do not configure routes or write schemas. The certified pipeline already handles the parts that usually consume a sprint:
- Pagination, including the awkward dependent kind where one call decides the next.
- Watermarks and incremental loads, so a re-run does not re-pull the year.
- Schema drift, when a vendor adds a field without telling anyone.
- Delete detection, so rows removed at the source stop being reported as current.
When a vendor changes their API we change the connector, on our side, and your pipeline keeps running.
Or skip the pipeline entirely
Supported sources can be queried the moment they connect, straight against the source, with no sync and no copy. That is usually the fastest way to find out whether the data is worth keeping before you commit to a schedule for it.
When a data pipeline breaks at 3am
Run history, row counts and failure alerts to Slack, Teams or email. The point of the alert is that you find out before the person who opens the dashboard does.