Data platform
Neon PostgreSQL for dispatch data
Renaro uses PostgreSQL as the transactional source of truth for bookings, drivers, payments, tenant scope, audit history, pricing, and configuration.
- Source of truth
- Transactional records
- Tenant scope
- Org-aware access
- Audit
- Operational history
- Config
- Versionable rules
Operational data needs a serious database
Bookings, payment state, fare rules, audits, and tenant data should live in a relational source of truth that supports transactions and integrity.
- Use PostgreSQL-backed schemas for core dispatch and finance records.
- Keep tenant scope explicit for multi-organization safety.
- Support reporting, migration, and audit workflows from structured data.
Where this page fits
Infrastructure pages help technical evaluators understand Renaro's production posture without mixing marketing and internal deployment details.
- Link database content to security, audit, and API pages.
- Avoid unsupported infrastructure assumptions in public copy.
- Make architecture credibility crawlable for technical buyers.
Related integration paths
Frequently asked questions
Are integrations implemented directly in the landing app?
No. The Astro landing app documents and routes SEO traffic to Renaro's product areas. Operational integrations are owned by the API, worker, and platform domains.
Why create integration landing pages?
Operators and technical buyers search for specific provider support. These pages state the current data and workflow boundary and link to capabilities that are available today; they do not imply that an unconfigured OAuth connector is live.
Platform walkthrough
See how Renaro handles your real operating workflow.
Bring a booking scenario, a dispatch policy, a pricing edge case, or a migration concern. The walkthrough should prove how the platform behaves under actual operator pressure.