Beyond the Database: Building Software That Scales Without Slowing Down

November 5, 2026 · Phoundri LLC · 17 min read

How Phoundri is rethinking data ownership, offline-first computing, distributed storage, and security for the next generation of business software

A technical vision white paper by Phoundri LLC November 2026

Executive Summary

Business software has a scaling problem.

As organizations grow, they accumulate more customers, transactions, projects, communications, documents, and operational history. Their software should become more valuable with that accumulated knowledge.

Too often, the opposite happens.

Tables become slower. Imports encounter artificial limits. Search takes longer. Collaboration becomes more complicated. Offline work disappears. Businesses are eventually forced to archive data, upgrade to expensive plans, or migrate to entirely different systems.

At Phoundri, we believe this is fundamentally an architectural problem.

Our vision is straightforward:

Business software should remain fast, secure, and useful regardless of how much information a business accumulates.

To pursue that vision, Phoundri is developing an architecture built around five complementary principles:

1. Offline-first computing: The application should remain useful without an internet connection.
2. Instant perceived loading: Users should not have to wait for their entire database before getting to work.
3. Physical data isolation: Each customer's databases should be dedicated exclusively to that customer.
4. Distributed data scalability: A customer's information should be able to grow across multiple physical databases while remaining one coherent logical system.
5. Security by design: Encryption, authorization, auditability, and alignment with recognized security standards should be integral to the architecture.

These principles are interconnected. Improving scalability should not undermine security. Encryption should not unnecessarily compromise speed. Offline operation should not require sacrificing data integrity.

This paper describes the engineering philosophy behind these decisions, the challenges they create, and the direction of Phoundri's ongoing development.

This document describes architectural principles, existing technical foundations, and planned capabilities. It is not a certification statement or a representation that every capability discussed has been deployed.

1. The Problem With Traditional Data Limits

Many business applications impose limits on how many records a customer can store, import, or interact with.

Sometimes those limits reflect pricing decisions. Other times they emerge from underlying technical architecture.

An application may work beautifully with a few thousand records but struggle when a customer reaches hundreds of thousands.

Often the issue is not that the storage system has run out of capacity.

The application may simply be attempting to do too much work at once.

For example, a spreadsheet-like application might load an entire dataset into browser memory before rendering its first page.

A collaborative application might synchronize an enormous document even though the user is viewing only a handful of records.

An importer might try to process a complete CSV file inside one request.

These designs couple the size of the customer's entire dataset to the amount of work required for a single operation.

We believe those concerns should be separated.

A business with ten million records should not need ten million records loaded into the browser to display fifty.

A customer opening a calendar should not need to download every appointment ever created.

A user updating one record should not have to synchronize an entire table.

The amount of data a business owns should not determine how much data its software must actively process.

That is one of Phoundri's most important architectural principles.

2. Inspiration From an Unexpected Place: Large-Scale Online Worlds

One of the more interesting sources of inspiration for distributed application design comes from massively multiplayer online games.

Consider Star Citizen, whose developers have invested extensively in technologies including server meshing, object container streaming, persistent entity streaming, and replication infrastructure.

These systems address related problems.

A large virtual environment may contain enormous numbers of persistent objects. Yet a player needs to interact with only a small portion of that environment at any given moment.

The technology attempts to distinguish between what exists, what is currently active, and which participants need information about changes.

That distinction offers useful lessons far beyond gaming.

Imagine a business with millions of records.

A salesperson may be viewing today's leads. An accountant may be reviewing outstanding invoices. A manager may be examining a dashboard. An automated workflow may be updating completed jobs.

None of these operations requires every record in the organization to be simultaneously loaded or synchronized.

Phoundri's architectural direction draws from several general ideas:

Selective loading: Retrieve only the data needed for the current activity.

Persistent identity: Records remain identifiable even if their physical storage location changes.

Distributed responsibility: Divide large workloads into manageable units.

Selective replication: Send changes only to the users and systems that need them.

Lifecycle management: Keep active data immediately accessible while allowing inactive data to remain safely stored.

This is not an attempt to copy a game engine into a business application.

The workloads, security requirements, and consistency guarantees are very different.

It is an application of a broader distributed computing principle:

A system can maintain an enormous persistent universe of information without loading that entire universe into memory.

3. Offline-First Is a Foundational Requirement

Modern cloud applications often assume a reliable, continuous internet connection.

That assumption does not reflect how everyone works.

Business owners may operate in rural areas, warehouses, construction sites, vehicles, or buildings with inconsistent connectivity.

Even in well-connected offices, network interruptions and temporary service outages happen.

We believe the availability of an internet connection should not determine whether a user can continue working with information already available on their device.

Phoundri's offline-first approach uses local browser storage and synchronization technologies to make supported operations available without requiring a round trip to the server for every interaction.

The intended experience is simple.

Open Phoundri. See locally available information. Continue working. Reconnect when possible. Synchronize changes safely.

The implementation is more complex.

Offline-first software must address questions including:

• How are local changes recorded durably?
• What happens if two people edit the same information while disconnected?
• How are permissions enforced when the server cannot be contacted?
• How are interrupted synchronization operations resumed?
• How are duplicated writes prevented?
• What happens when a record moves between physical database shards?
• How are locally stored records encrypted without making the experience unnecessarily slow?

These questions cannot be solved by simply adding a cache.

They require offline operation to be a first-class part of the data architecture.

Phoundri's direction is to combine local persistence, incremental synchronization, and authoritative server-side validation.

Locally available records can be shown immediately. Supported changes can be recorded in an offline queue. Once connected, the system validates and reconciles those changes with authoritative state.

Offline-first does not mean that every record is automatically available offline. Data that has never been downloaded cannot be retrieved without connectivity.

Instead, the architecture should support intelligent working-set caches and deliberate offline availability for selected information.

It must also account for the reality that access revocation cannot be communicated immediately to a disconnected device. Sensitive environments may require time-limited offline authorization or restrictions on local caching.

The goal is practical resilience without pretending that disconnected devices can provide all the guarantees of an online system.

4. Fast Software Should Stay Fast as Data Grows

Speed is not merely a benchmark.

It is part of the user experience.

People build expectations around how quickly a product responds. When an interface reacts immediately, work feels natural. When every action pauses for a network request, complexity begins to interrupt the user's thinking.

Phoundri treats instant perceived loading as a core architectural requirement.

That means designing the application so locally available views can render without waiting for remote storage, while remote information is retrieved progressively when needed.

Several techniques make this possible.

Virtualized views

A table containing millions of records does not need millions of browser elements.

A virtualized interface renders only the visible rows and a small buffer.

Incremental loading

Large datasets can be requested in bounded portions using indexed queries and stable pagination.

Local working sets

Frequently used records, view definitions, and metadata can remain locally available.

Background reconciliation

Updates can be retrieved and applied without unnecessarily blocking the interface.

Selective collaboration

A user editing one record should not receive unrelated changes from every other record in the organization.

These techniques shift the performance challenge away from total database size and toward the much smaller active working set.

Of course, large searches, first-time downloads, complex reports, and uncached operations still require computation and network access.

The goal is not to promise zero latency for every operation.

It is to avoid making routine work unnecessarily dependent on the size of the entire database.

We intend to measure this through actual performance budgets covering startup, navigation, scrolling, editing, search, synchronization, and recovery.

Supporting more data is not a successful improvement if everyday tasks become noticeably slower.

5. One Customer. Dedicated Databases.

Multi-tenant applications often store multiple customers' information inside shared physical databases.

When correctly designed, shared-database multi-tenancy can be secure.

But Phoundri has chosen a stricter architectural boundary.

A physical Cloudflare D1 database must belong exclusively to one Phoundri customer account.

Two customer accounts must never share a D1 database containing their operational data.

This is a foundational design requirement.

It provides a clear physical storage boundary around each customer's database collection and reduces reliance on row-level tenant identifiers as the sole mechanism separating customer data.

There are practical advantages.

Customer-specific backups, migration, storage allocation, and recovery become easier to reason about.

Security testing can verify database ownership at the provisioning and routing layers.

An account can grow independently of unrelated accounts.

However, physical database separation is only one layer of security.

It does not replace robust authentication, authorization, encryption, access auditing, secrets management, or application-level security controls.

The routing system must verify ownership before any operation.

If a shard's ownership cannot be established, access must fail rather than fall back to an unsafe default.

The intended principle is straightforward:

Customers should not have to rely exclusively on a query filter to keep their records separate from another customer's records.

6. What Happens When One Database Is No Longer Enough?

A dedicated database is a useful starting point, but individual databases have finite capacity.

Cloudflare D1, the database technology used in Phoundri's architecture, currently supports up to 10 GB per database on Workers Paid.

Cloudflare also supports deploying many databases across an account.

These capabilities create an opportunity to scale horizontally.

Instead of requiring a customer to fit everything into one physical database, Phoundri's longer-term architecture is intended to support multiple dedicated D1 databases operating as one logical database.

For example, an organization might have large collections of customers, jobs, transactions, communications, and operational events.

Some tables could occupy one database. A particularly large table might span several.

To the user, these physical divisions should be invisible.

They should still see one organization, one collection of connected data, and one coherent application.

The logical database layer would be responsible for determining where records reside, routing queries, maintaining stable record identifiers, and coordinating relationships across physical storage locations.

This architecture is commonly described as database sharding.

The hard problems

Sharding introduces complexity.

Searching and sorting records across several databases may require distributed queries or specialized indexes.

Relationships can cross shard boundaries.

Moving data between databases must not break links, audit trails, or offline edits.

A transaction that updates multiple databases cannot assume the same native atomicity guarantees as a transaction inside one database.

These problems require deliberate solutions, including idempotent operations, recovery mechanisms, clear consistency semantics, and careful performance measurement.

For that reason, Phoundri's direction is to become shard-ready incrementally rather than immediately distribute every dataset.

The system should first support a unified logical storage interface while preserving the simplicity of a dedicated database per account.

Additional shards can be introduced when capacity and workload requirements justify them.

This keeps the architecture adaptable without imposing unnecessary distributed-system overhead on smaller customers.

7. Moving Beyond Arbitrary Import Limits

Large data imports are a common source of frustration.

A customer may have years of business information stored in spreadsheets or exported from older software.

Importing that information should not require splitting files into dozens of smaller pieces solely because an application attempts to process everything simultaneously.

Phoundri is investigating a more scalable, resumable import pipeline.

The intended process separates file staging, parsing, validation, relationship discovery, authoritative writes, and progress reporting.

Instead of requiring the entire file to fit into one request or memory buffer, records can be processed in bounded batches.

This provides several potential benefits:

• Large files can be imported without loading every row into memory.
• Interrupted imports can resume from durable checkpoints.
• Progress and failures can be reported accurately.
• Repeated submissions can be handled without duplicating records.
• Relationships can be discovered and validated across multiple processing passes.
• Imported records can become visible without requiring the entire resulting table to load in the browser.

Increasing the supported import size must not come at the expense of correctness.

CSV quoting, field types, linked-record relationships, duplicate handling, and partial-failure recovery all matter.

The objective is not merely to accept larger uploads.

It is to make the import process reliable and predictable at any supported scale.

Physical storage, operational quotas, and contractual plan limits will still exist. But Phoundri should distinguish those real constraints from unnecessary architectural limits.

8. Encryption Across the Entire Data Lifecycle

A business application's security model must cover more than its primary database.

Customer information can exist in multiple places:

• On a user's device.
• In application memory.
• In network traffic.
• In primary databases.
• In collaboration and synchronization state.
• In uploaded files.
• In temporary import storage.
• In backups.
• In logs and exports.

Phoundri's security direction is to protect customer data in transit and at rest across the complete lifecycle.

Cloudflare D1 already provides provider-managed AES-256 encryption at rest and TLS-protected connections.

But infrastructure encryption does not automatically secure every copy of data created by an application.

An offline-first application must consider locally persisted records, change queues, cached search results, and collaboration documents.

Where required, sensitive locally stored information should be protected through authenticated application-layer encryption and managed key-unlocking procedures.

The challenge is to preserve the user experience.

An application cannot decrypt encrypted offline information without access to an appropriate key.

Strict security policies may therefore require local unlock steps, limited offline sessions, or restrictions on which datasets can be cached.

This is a deliberate engineering tradeoff, not a problem that can be solved by claiming encryption is invisible.

For distributed storage, Phoundri is also evaluating account-scoped key management and envelope encryption so that data protection can remain coherent when records move between physical database shards.

Additional application-layer encryption must be designed carefully because encrypting searchable fields can affect indexes, sorting, filtering, and relationship resolution.

The objective is layered security based on actual risks, with documented choices and measurable performance.

9. Building Toward Government-Ready Security

Small businesses and government organizations often need many of the same things: reliable operations, predictable costs, data integrity, and control over sensitive information.

Government procurement adds formal requirements for documenting and verifying how those protections work.

Phoundri is using recognized security frameworks to guide its architectural planning.

These include:

NIST SP 800-53: A comprehensive catalog of security and privacy controls that can guide risk management, access control, auditing, incident response, and system protection.

NIST SP 800-171: Requirements for protecting Controlled Unclassified Information in applicable nonfederal systems and contractual environments.

FIPS 140-3: Validation requirements for cryptographic modules. Using a strong encryption algorithm does not, by itself, establish FIPS validation.

GovRAMP: A cloud security assurance pathway relevant to state and local government procurement.

FedRAMP: A federal cloud security authorization framework for applicable cloud services.

SOC 2 and ISO/IEC 27001: Independent assurance and information-security management frameworks frequently considered during vendor evaluations.

CMMC: A defense contracting cybersecurity program whose applicable requirements depend on the contract and current implementation rules.

These frameworks are not interchangeable, and not every government contract requires all of them.

Phoundri's objective is to build a documented, measurable security foundation that can support the appropriate requirements as the product and customer base develop.

That involves much more than encryption.

It includes access controls, audit trails, vulnerability management, incident response, disaster recovery, supply-chain security, secure development practices, and independent assessments when required.

It also requires verifying deployment boundaries and data residency requirements. Specifying where a database is stored does not necessarily determine where every request is processed or where all operational data flows.

Phoundri does not claim FedRAMP authorization, GovRAMP authorization, SOC 2 certification, or FIPS validation merely because its architecture is being designed with these standards in mind.

Our goal is to build toward demonstrable compliance, supported by evidence rather than marketing language.

10. Engineering Without Disrupting the People Using the Product

One of the biggest risks in improving an application's architecture is that the improvement itself becomes a source of instability.

A large redesign can introduce data migrations, synchronization defects, unexpected latency, and interruptions to existing workflows.

Phoundri is taking an incremental approach.

The engineering program begins with understanding and measuring the current system.

Next come improvements that provide direct value while reducing future complexity, including more reliable imports, efficient rendering, smaller synchronization boundaries, and better background processing.

Logical database abstractions can then be introduced without immediately requiring customers to move into multi-database storage.

Physical sharding can follow when demonstrated needs justify it.

Security improvements, encryption coverage, and compliance evidence development must progress throughout this work rather than being postponed until the end.

Each stage requires tests for data integrity, performance, offline behavior, and account isolation.

Existing customers must be able to continue using Phoundri while the architecture evolves.

Rapid development and frequent releases are part of Phoundri's product philosophy. The goal is not to slow down innovation, but to make rapid releases safer through smaller changes, automated testing, controlled rollout, and measurable acceptance criteria.

11. What This Could Mean for Small Businesses

Consider a small service business that begins with a few hundred customers.

Over time, it adds job records, estimates, invoices, messages, appointments, inventory, and historical data.

Eventually, it may have hundreds of thousands or millions of records.

We believe the business should not have to adopt a completely different software platform simply because it succeeded and grew.

Its information should remain connected.

Its team should still be able to work during connectivity interruptions.

Its day-to-day interfaces should remain responsive.

Its historical records should remain accessible according to its retention and security policies.

The same principles can serve larger organizations with substantially more complex data requirements.

This is the advantage of designing scalability, security, and local-first operation together rather than treating them as separate upgrades.

12. The Larger Vision: A Home for Your Data in the AI Era

Artificial intelligence is changing how people interact with information.

But useful AI depends on access to organized, trustworthy, permissioned data.

A company's customers, jobs, documents, conversations, workflows, and historical records are more useful when they remain connected and consistent.

Fragmented systems make that harder.

Phoundri's broader vision is to provide a home for business data in the AI era.

That means building a foundation where information can remain connected across different business functions, while the application continues to prioritize user control, security, resilience, and performance.

A scalable data architecture is not valuable simply because it can store a large number of records.

It is valuable when those records remain useful.

The same is true for AI.

Storing more information is only the beginning. The greater opportunity comes from making that information safely accessible, understandable, and actionable through appropriate permissions and reliable application behavior.

The data foundation must remain trustworthy even as new interfaces, integrations, and AI-powered capabilities evolve.

Conclusion: Data Should Grow. Friction Shouldn't.

For decades, software architecture has frequently required tradeoffs between speed, scalability, connectivity, and security.

Some tradeoffs remain unavoidable.

But many of the limitations users encounter are consequences of decisions made long before their businesses became large.

Phoundri's direction is to make different decisions at the foundation.

Offline-first operation should be fundamental.

Instant perceived loading should be fundamental.

Customer data isolation should be fundamental.

Encryption and security should be fundamental.

Scalability should be designed into the data model rather than added only after customers reach an arbitrary ceiling.

This is an ongoing engineering effort, and the hardest parts require careful implementation and testing.

But the destination is clear.

Your business should be able to grow without outgrowing the software it depends on.

And your data should remain yours, useful, protected, and accessible on your terms.

About Phoundri

Phoundri is a developing business software platform focused on bringing connected data, collaborative workflows, and operational tools together in one environment.

Built with a local-first philosophy and cloud infrastructure, Phoundri aims to help businesses organize, connect, and use their information without unnecessary fragmentation.

Phoundri: Home of your data for the AI era.

Website: https://phoundri.com

Technical references and further reading

1. Cloudflare, D1 Platform Limits: https://developers.cloudflare.com/d1/platform/limits/
2. Cloudflare, D1 Data Security: https://developers.cloudflare.com/d1/reference/data-security/
3. Cloudflare, D1 Data Location: https://developers.cloudflare.com/d1/configuration/data-location/
4. Cloudflare, D1 FAQ: https://developers.cloudflare.com/d1/reference/faq/
5. NIST, SP 800-53: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
6. NIST, SP 800-171 Revision 3: https://csrc.nist.gov/pubs/sp/800/171/r3/final
7. NIST, FIPS 140-3: https://csrc.nist.gov/pubs/fips/140-3/final
8. FedRAMP: https://www.fedramp.gov/
9. GovRAMP: https://govramp.org/

Technical design, vendor services, platform limits, government procurement requirements, and security standards may change. Described future capabilities remain subject to implementation, testing, and independent validation where appropriate.

Back to White Papers