Distributed Data on CloudFlow

Native Data on CloudFlow

Ephemeral Volumes

Whenever your container opens a file for writing, you are using CloudFlow's ephemeral volumes. This storage goes away when the pod terminates.

Persistent Volumes

By using a Persistent Volume Claim you can share a filesystem across multiple pods. Using this technology you can share virtually any data technology between pods, such as relational databases, document stores, object stores, key-value stores, and message queues. Sharing across pods can occur in the following instances:

• horizontal scaling of a pod, so that the multiple replicas have access to shared data
• different pods of a microservice application, giving those pods a common source of truth for whatever data they might need
• data that needs to survive a pod that crashes and restarts

Check out our tutorial to see how this works for a Postgres deployment.

Streaming Database Backups

Depending upon your circumstances, when you house your database at an edge location then you may wish to stream a backup to a more permanent location such as AWS S3, Azure Blob Storage, Wasabi, Exoscale, etc. Litestream.io supports this idea for SQLite.

Re-populating a Database as CloudFlow Relocates It

Streaming backup technology, such as Litestream.io mentioned previously, can also be used to repopulate a database as CloudFlow moves your project from one region to another.

Synchronized Databases

Strategies for sharing data between locations include configuring replication to occur between persistent volumes residing in different locations. We have a guide that explains how you can set this up (coming). You might choose to use a static location configuration for your project and then replicate data between them in order to provide a globally-distributed persistent data.

Serverless Data Integrations

Below are a few managed serverless data offerings that we are aware of at CloudFlow. We've written tutorials for a few. Almost all offer some kind of multi-region replication, which is useful for disaster recovery, high-availability, and low-latency reads for better performance for geographically distributed end users. Those that support multi-region writes are listed separately. The data landscape has lots of options to choose from, many of them free for limited usage.

Data Type	Single-Region Write	Multi-Region Write
Relational (SQL)	Supabase, Neon, Aiven for PostgreSQL, bit.io (Postgres compatible)	Polyscale.ai, CockroachDB Serverless (multi-region write is in preview)
Document (NoSQL)	MongoDB Atlas	FaunaDB, DataStax Astra DB (Cassandra-based), HarperDB, Couchbase Capella
Key-value	ZippyDB, Aiven Redis, ScaleGrid Redis	Upstash Redis
Object storage	Wasabi, Backblaze	Synadia Jetstream Object Store (NATS.io-based)
Message Queue	Upstash Kafka	Synadia (NATS.io-based)