> ## Documentation Index > Fetch the complete documentation index at: https://docs.cedarai.com/llms.txt > Use this file to discover all available pages before exploring further. # Choosing the right option > Postgres views, API clients, MCP, and CDC delivery overlap in the data they reach. Here is how to decide which one fits. 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. | If the consumer is… | Use | Why | | - | - | - | | A **person** asking questions in plain language | [MCP](/user-docs/data-depot/mcp) | Answers come back in a conversation, under that person's own access | | An **analyst or BI tool** exploring and reporting on tables | [Postgres views](/user-docs/data-depot/postgres) | SQL over whole tables, with joins, filters, and aggregates | | An **application or integration** acting as part of a workflow | [API clients](/user-docs/data-depot/api-clients) | Targeted calls for specific records and actions, with a key that isn't a person's login | | A **data platform** that keeps its own copy, such as a lakehouse or warehouse | [CDC delivery](/user-docs/data-depot/delivery) | Cedar sends a snapshot and then every change, and your platform takes it from there | ### 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. | Option | Who can see what | | - | - | | **MCP** | Each person sees only what their own ARMS permissions allow | | **API clients** | Only the endpoints you selected, and only what the assumed user's ARMS roles allow | | **Postgres views** | Anyone with the database login can read the whole view for the carrier. Treat the password as a shared service secret | | **CDC delivery** | Once the files land, whoever you give access to your storage. Your own access controls apply from then on | ## Side by side | Option | How data moves | Can change Cedar data | Access follows | | - | - | - | - | | **MCP** | Pull, live, a small page at a time, on Cedar's service level | No | The person's own ARMS permissions | | **API clients** | Pull, live, per record or page, on Cedar's service level | Yes, on the endpoints you select | Selected endpoints and the assumed user | | **Postgres views** | Pull, live, whole tables with SQL, on Cedar's Postgres service level | No | Whoever holds the database login | | **CDC delivery** | Push, a copy in your storage updated every 5, 10, or 15 minutes, on your own SLA once delivered | No | Your own storage permissions | 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: Ask questions with **MCP**, or point a SQL client at a **Postgres view** to see what the data looks like. Connect your BI tool to the **Postgres view** for live dashboards. When a dashboard or model becomes something the business relies on, switch it to **CDC delivery**. Then it runs on your own copy and your own SLA. Add an **API client** when a system needs to look up specific records on demand or write back to Cedar. ## 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](/user-docs/data-depot/overview) * [Postgres views or CDC delivery?](/user-docs/data-depot/postgres#postgres-views-or-cdc-delivery) * [Access and permissions](/user-docs/data-depot/access) ## Related topics - [Cedar Data Depot](/user-docs/data-depot/overview.md) - [API Introduction](/user-docs/api-reference/introduction.md) - [MCP privacy addendum](/user-docs/api-reference/mcp-privacy.md) - [QuickBooks Web Connector](/user-docs/accounting-integrations/quickbooks-web-connector.md) - [Inventory](/user-docs/mobile/inventory.md)