Organization
An organization is the top-level tenant for billing, SSO, and global policies. All users, projects, and audit settings roll up to an organization. Large companies often run one organization per subsidiary or one shared organization with strict project boundaries—your admin chooses based on compliance and cost allocation. You use it to: enforce login methods, store default data residency settings, and delegate org-wide admin roles.Project
A project groups connections, pipelines, schedules, and reverse ETL syncs that belong to one team or use case. Projects are where you grant collaborator access: a marketing analyst might have edit rights inGrowth analytics but read-only access in Finance.
You use it to: isolate secrets, separate sandbox from production, and organize navigation for dozens of pipelines.
Connection
A connection stores how Planasonix reaches a system: hostnames, OAuth tokens, service accounts, SSH tunnels, or file paths. Connections are reusable; many pipelines can read from the sameSnowflake prod connection without duplicating credentials.
You use it to: centralize rotation (when a password changes, you update one object), test connectivity independently of a pipeline, and apply row-level policies about who may use which environment.
Pipeline
A pipeline is a versioned graph of nodes that moves data from one or more sources to one or more destinations. Pipelines have their own run history, schedules, and alert rules. Saving a pipeline creates an immutable revision you can compare in the UI or API. You use it to: define the end-to-end data path—extract, transform, validate, load—and to promote the same logical flow from dev to staging to prod with controlled merges.Node
A node is a single step on the canvas: extract from a connection, SQL transform, schema enforcement, branch on success or failure, call a webhook, and so on. Nodes declare inputs and outputs so Planasonix can order execution and show lineage. You use it to: break work into testable units, reuse patterns (the same dbt invocation node type across pipelines), and pinpoint failures when only one step breaks.Schedule
A schedule triggers pipeline runs on a cadence (cron-style or simple every-N-minutes) or in response to an external event if your workspace enables event-driven triggers. Schedules respect concurrency limits and maintenance windows configured by admins. You use it to: run nightly warehouse loads, kick off hourly micro-batches, or pause runs during known downtime without deleting the pipeline.Reverse ETL sync
A reverse ETL sync is a configuration that reads from a modeled table or query in your warehouse (or lakehouse) and writes rows into an operational system such as HubSpot, Iterable, or a custom REST API. Syncs define primary keys, column mappings, delete behavior, and rate limits. You use it to: push curated segments and metrics to teams who live in SaaS tools, while keeping the warehouse the source of truth for analytics logic.How the pieces fit together
- Batch analytics
- Streaming
- Reverse ETL
You create connections to source DBs and the warehouse, build a pipeline with extract and load nodes, then attach a schedule for nightly runs inside a project scoped to your team.
Next steps
- Quickstart — Hands-on first pipeline.
- Introduction — Capabilities and architecture diagram.