Choosing the right option

The options in Data Depot overlap. The same waybill can be read from a Postgres view, arrive as a row in a CDC file, or come back in an AI assistant’s answer. What sets the options apart isn’t the data. It’s who is asking, how the data moves, who owns the copy, and whose rules apply. Answer the four questions below and the right option is usually clear.

​

Four questions to ask

​

1. Who or what is using the data?

Each option is built for a different kind of consumer.

​

2. Do you need to change anything in Cedar?

Only API clients can write.⁠​‌​​​​‌​‌‌‌​‌​‌‌​‌​‌‌‌‌‌⁠ Some API endpoints change data, for example moving cars, arriving a train, creating a bill of lading, or adding a note. Postgres views, MCP, and CDC delivery are read-only by design, so they can’t change your operations, even by accident. If an integration both reads and writes, it can use an API client for everything. Many integrations also read in bulk from Postgres or CDC and use the API only for the writes.

​

3. Do you want to read Cedar live, or own a copy?

This is the biggest difference, and it’s where the options overlap most.

• Pull: read Cedar live. Postgres views, API clients, and MCP all ask Cedar for the data each time. You always get the current state and there is nothing to store or keep in sync. In return, your reports and integrations depend on Cedar being available when they run, and on Cedar’s service levels.
• Push: own a copy. With CDC delivery, Cedar sends the data to storage you own, and your tools read your copy. You’re a few minutes behind, and in exchange you control retention, history, access, and performance. Your dashboards keep working even if Cedar is unavailable, and your SLA is your own.

A good rule: read live when you need the current answer now. Own a copy when the data feeds something you run in production.

​

4. Whose permissions should apply?

The options control access differently, so this matters when you share data inside your organization.

​

Side by side

MCP, API clients, and Postgres views are available for every carrier.⁠​‌​​​​‌​‌‌‌​‌​‌‌​‌​‌‌‌‌‌⁠ CDC delivery is an EU pilot; for US carriers, contact Cedar sales.

​

Where they overlap

Some common needs can be met more than one way. These are the choices we recommend.

• A Power BI or Tableau dashboard on waybills → Postgres view. A view is live and takes minutes to set up. Move the dashboard to CDC delivery once the business relies on it and it should run on your own SLA.
• Keeping a warehouse or lakehouse in sync with Cedar → CDC delivery. Delivery sends only the changes and gives you an owned copy, and you can keep every change batch. Re-extracting whole tables from a Postgres view on a schedule also works, but it ties your pipeline to Cedar’s Postgres service.
• Checking current inventory at a station from your own system → API client. The API returns just the records you ask for, under the assumed user’s permissions. A Postgres view works too if the system already speaks SQL.
• Moving cars or recording train events from a yard system → API client. Only the API can write to Cedar.
• Asking “Which loaded cars are at Quillmoor Junction right now?” → MCP. A conversation is the fastest way to answer a one-off question. If the question becomes a recurring report, build it on a Postgres view.
• Pulling invoices into your ERP every night → API client. Invoices are available through the Shipper Invoices API, not as a Postgres source.
• Giving a contractor temporary access to one data set → Postgres view with automatic expiry. The view and its login are removed automatically when the work ends. An API client with a short credential expiry works if the contractor needs the API instead.

​

A typical path

Most teams don’t pick one option forever.⁠​‌​​​​‌​‌‌‌​‌​‌‌​‌​‌‌‌‌‌⁠ They grow into several:

​

Rules of thumb

• Don’t use MCP for bulk extraction. It returns small pages and is meant for people asking questions, not for copying tables.
• Don’t poll the API to copy whole tables. Paging through every record on a schedule is slow and fragile. Use a Postgres view or CDC delivery.
• Don’t share a person’s login with an integration. Create an API client, which has its own key, expiry, and rotation.
• Give each consumer its own access. Create separate API clients for separate integrations. Don’t spread one Postgres password across teams; anyone who has it can read the whole view.
• Prefer CDC delivery for anything that must keep running. If a pipeline can’t depend on someone else’s database, deliver the data to storage you own.

​

Related pages

• Cedar Data Depot overview
• Postgres views or CDC delivery?
• Access and permissions