Managed data

Tabbify offers PostgreSQL, key-value, and S3-compatible resources in early access. A resource belongs to one tenant and can be connected to approved applications. Availability of a resource type does not imply a complete highly available, disaster-recovery, or point-in-time recovery service.

Managed data is a shared responsibility. Your team owns schemas, queries, migrations, data classification, application retention, and safe client behaviour. Tabbify operates only the resource and procedures explicitly accepted into the engagement.

Choose the resource

An application may use all three, but each one needs its own failure and recovery decision.

Provisioning

The current console entry points are:

• Data -> Databases for PostgreSQL;
• Data -> Caches for KV;
• Data -> Buckets for S3-compatible object storage.

During early access, confirm the resource type, owning application, environment, expected size, network exposure, data sensitivity, and required recovery procedure before copying production data. Region choice, redundancy, retention, and recovery are not inferred from the create action.

Connections and credentials

Pass connection material through Tabbify-managed configuration or secrets. Do not commit database URLs, passwords, or access keys to Git.

A safe connection has separate controls:

1. Network reachability - the application has an approved tenant-private path or explicitly configured public endpoint.
2. Credentials - the application receives only the role or key it requires.
3. Service policy - database permissions, key namespaces, bucket policy, or prefixes constrain operations.
4. Application policy - the calling service still authenticates its users and validates requests.

A private address is not authorization, and a credential does not guarantee that the network path is available.

PostgreSQL

Use PostgreSQL for authoritative relational state. Separate production, staging, and development databases and credentials. Reserve owner credentials for controlled migrations and recovery; applications should use a narrower role.

Treat schema changes as releases:

• make the new schema compatible with the currently running application where practical;
• run each migration once from a controlled job;
• set lock and statement timeouts;
• record the migration revision with the source commit outside the platform;
• rehearse a forward fix or applicable restore before a destructive change;
• remove old columns only after all callers have moved.

Bound connection pools to the provisioned capacity. A new deployment must not create an unbounded number of connections, and retries must be limited to errors known to be transient.

Current PostgreSQL limit: the public early-access offer does not provide a complete highly available database service, automatic geographic failover, or user-facing PITR. Backup and restore coverage depends on the specific resource and written operating scope. Do not assume a recovery objective that has not been exercised for that resource.

KV

KV is suitable for caches, expiring tokens, rate counters, coordination, and state that can be reconstructed. Prefix keys by application and environment, set TTLs where appropriate, and keep values bounded.

Decide explicitly whether each value is cache or authoritative state. If losing it would lose a business record, keep the authoritative copy in PostgreSQL or define and test a resource-specific persistence and restore procedure.

Current KV limit: persistence, backup, failover, and eviction behaviour depend on the selected profile and engagement. The early-access service is not a blanket durable-record guarantee.

S3-compatible object storage

Use object storage for complete objects addressed by key: uploads, media, exports, datasets, and artifacts. Keep credentials out of object keys, separate private originals from public derivatives, and make retried uploads safe.

S3 compatibility should be tested with the exact client operations your application uses. Do not assume support for every AWS API, lifecycle rule, versioning behaviour, checksum mode, or event integration. Object storage is not a POSIX filesystem and does not provide arbitrary in-place file updates.

Current object-storage limit: advanced S3 features, geographic redundancy, and full-bucket disaster recovery are not part of the general early-access promise. Record any required feature and verify it during the pilot.

Backup and restore

The current service does not offer complete HA, full DR, or universal PITR across these resource types. Some backup and restore paths exist and selected paths have been exercised, but that evidence must not be generalized to every resource, failure mode, or retention period.

Before production use, write down:

• exactly what is backed up and by which mechanism;
• how much recent data may be lost;
• how long the applicable restore may take;
• retention and deletion rules;
• who can request and verify recovery;
• the last successful exercise using this resource's actual path.

A restore exercise must validate application behaviour and data consistency, not only that an archive can be opened. If the required failure mode has no exercised recovery path, treat it as an accepted risk or keep the data elsewhere.

Production checklist

• [ ] The resource is marked early access in the architecture decision.
• [ ] The owner, environment, consuming applications, and exposure are recorded.
• [ ] Application and migration credentials are separate.
• [ ] Secrets are injected and rotation is documented.
• [ ] Pools, timeouts, retries, TTLs, and object sizes are bounded.
• [ ] Required client operations have been tested against the exact service.
• [ ] Backup scope, tolerated loss, recovery time, and retention are written down.
• [ ] The applicable restore path has been exercised, or the gap is explicitly accepted.
• [ ] Deletion and offboarding behaviour are agreed.

For the surrounding human operating model, see Managed operations. For application reachability, see Private Mesh.