Amplitude to Databricks: How to Move Your Data
Move Amplitude into Databricks with Airbyte. The 4 GB export limit and Request Time Range, choosing the right data region, and modelling nested event properties.
Moving Amplitude into Databricks puts behavioural data where it can be modelled rather than only reported. Amplitude is excellent at product analytics and knows nothing about revenue, support cost or contract value, and questions about what a behaviour is worth need both sides.
This guide covers the managed path with Airbyte. One setting determines whether your first sync completes, because the Export API caps each request at a fixed size and a busy product generates more than that in a day.
Amplitude to Databricks at a glance:
Why move data from Amplitude to Databricks?
Two situations account for most of these pipelines.
The first is modelling rather than reporting. Propensity models, churn prediction and recommendation work need notebooks, Spark and feature engineering over the raw event stream, which is a different activity from reading a funnel chart.
The second is joining behaviour to commercial outcomes under one governance model. If your questions are funnels and retention curves, Amplitude answers those well already and this pipeline earns you little.
What do you need before you start?
Two credentials and two settings that quietly decide whether the first sync succeeds:
An Amplitude API key and secret key. Both found in your Amplitude project settings, and they are per project rather than per account, so a multi-project setup means a source per project. The Amplitude source documentation lists every field.
The correct data region. The setting defaults to the standard server, and if your Amplitude project sits in the EU data centre you must select the EU residency server instead. Getting this wrong produces a connection that cannot find your data rather than a helpful message.
A deliberate start date. Leaving it blank replicates everything, which on a mature project is an enormous first sync against an API with a hard size ceiling per request.
Unity Catalog access. Each stream becomes a table in Unity Catalog and the connector needs permission to create Volumes for Avro staging. Agree the catalog and schema before the first sync, particularly since event data identifies users.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build an Amplitude to Databricks pipeline in Airbyte?
Step 1: Estimate your daily event volume
Find out roughly how many events your project records per day, because that number determines your Request Time Range before you touch anything else. The Export API caps each export at 4 GB, and a high-traffic consumer product generates well past that in twenty-four hours.
Step 2: Configure the Amplitude source
Click Sources in the left navigation, then New Source, and select Amplitude, following adding a source. Supply the API key, secret key, data region and start date, then set the Request Time Range, which controls how many hours of events each request covers and defaults to 24.
Step 3: Configure the Databricks destination
Click Destinations, then New Destination, and select Databricks, following adding a destination. Supply your workspace details, the catalog and schema, and authentication. Event properties are nested and the connector preserves that structure, which suits this destination because working with nested data in Spark is ordinary rather than awkward.
Step 4: Create the connection and backfill carefully
Click Connections, then New connection, select your streams and an incremental sync mode where available. Run the backfill with a short Request Time Range even if steady state would tolerate the default, because the historical period is where the size ceiling bites and a failure six hours in costs you those six hours.
Unlike a relational destination there is no volume ceiling to design around here, so the constraint is entirely on the way out of Amplitude rather than on what Databricks can absorb.
Why does the events stream fail or time out?
Because the Export API caps each export at 4 GB. Exceed it and the request errors outright. Get close to it and the request times out instead. Both failures have the same fix, which is reducing the Request Time Range so each request covers fewer hours.
For a low-volume product the 24 hour default is fine and you will never think about it. For a consumer app doing millions of events a day, a day of events is well past the ceiling and the first sync simply fails. Drop it to six hours, or one, and the same data moves in more, smaller requests.
The other streams come from the Dashboard REST API, which uses a cost-based budget. You do not manage that: the connector tracks what each request costs and throttles itself to stay inside the limits, so a slow sync there is expected behaviour rather than a fault.
How should you model event data in a lakehouse?
Treat the landed events table as a bronze layer. Amplitude event and user properties are nested and the connector preserves that structure, which is an advantage here rather than a problem, because Spark works with nested data natively and you lose nothing by landing it as it arrived.
Build a silver table extracting the properties your team queries into typed columns, and keep bronze so you can reprocess history when the product team adds a property. On a source where new properties appear without warning, that raw layer is what saves you starting from the day you noticed.
Then partition on the event date, because events accumulate indefinitely and a table that is never partitioned becomes expensive to scan. Establish that while there is one model to change rather than a set of notebooks, and decide who can read user-level rows while you are at it.
Frequently asked questions
Why does my Amplitude events sync fail or time out?
The Export API caps each export at 4 GB and large requests can time out. Reduce the Request Time Range so each request covers fewer hours.
My Amplitude project is in the EU. What changes?
Set the data region to the EU residency server rather than leaving the standard server default, otherwise the connector queries the wrong data centre.
Can one source cover several Amplitude projects?
No. Credentials are per project, so create one source per project and union them in your silver layer if you need a combined view.
Should I flatten event properties before loading?
No. Land the nested structure as bronze and extract into typed columns in a silver model, keeping the raw available for reprocessing when new properties appear.
Can I do this without writing code?
The Airbyte setup is entirely UI-driven. You will want Spark or SQL models extracting event properties and joining to your revenue data, which is where the analysis lives.
Get your Amplitude data into Databricks
Estimate your event volume and set the Request Time Range against it, get the data region right, and land events as bronze so the nested properties stay available for reprocessing. Then partition on event date and decide who can read user-level rows before anyone asks.
Airbyte's connector catalog includes 600+ pre-built connectors, so behavioural data can sit beside the revenue and support sources that explain it. For fan-out to several consumers, see Amplitude to Kafka, and for another product analytics source in a lakehouse, PostHog to Databricks.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.