Skip to content

Data Management - Tabular

PlaidCloud’s data layer is built around tables (structured row-and-column data) and views (saved queries over tables). Both live inside a project and are powered by the Lakehouse engine, which scales from small reference tables to billion-row analytical datasets without configuration changes.

  • Tables and views — what each is, when to use which, and how they interact
  • Table explorer — browse and inspect tables in your project
  • Currency data type — an exact, half-width column type for money values, and when to choose it over Numeric
  • Vector data type — store pre-computed embeddings in a project table, declare the width you expect, and search for the nearest rows
  • Table snapshots — browse snapshot history, view data as of a past snapshot, and revert or restore a table
  • Publishing data — make project tables available to dashboards, BI tools, and downstream systems, and review their performance guidance
  • Selecting the latest record in a large history table — a common pattern with a performance-aware solution
  • Geocoding API — migrate a Google or Mapbox geocoding integration to PlaidCloud’s REST geocoding endpoints
  • Drive-Time Routing API — opt-in preview: drive-time isochrones and nearest-by-drive-time ranking over REST

Tables are typically populated by workflows — automated pipelines that import data, transform it, and write results back. See Workflows for how to build them, and Workflow step reference for every step type you can use.

For connecting external systems as data sources, see Connections (guide) and Connectors (reference).

  • Concepts — how tables relate to workflows, dimensions, and the broader data model
  • Projects — projects own the tables; tables don’t exist outside a project
  • Dashboards — consume published tables for visualization