DEV Community: Mick Michaels

Why Fast-Growing Products Develop Slow Databases

Mick Michaels — Tue, 08 Sep 2026 15:02:45 +0000

Database performance problems are often described as sudden events. A product launches, traffic increases, and one day the application becomes slow. The team assumes the database has reached a hard limit and begins searching for a larger server or a new technology.
In reality, most slowdowns are cumulative. They emerge from hundreds of small product decisions: a query added for a new dashboard, a status field repurposed for another workflow, a background job that scans more records each week, or an integration that requests the same information repeatedly.
Traffic can expose the problem, but it is rarely the complete explanation. A growing product needs to understand how its data access patterns are changing, not only how many users it has.

Performance starts with workload shape

Two databases with the same amount of data can behave very differently. One may serve predictable lookups by identifier. The other may constantly filter, sort, group, and join records across several business processes.
The important questions are practical:

Which actions happen most often?
Which actions must feel immediate to the user?
Which reports can run later?
Which records change frequently?
Which requests read a narrow set of rows, and which scan broad periods?
Which workloads compete for the same resources?

Without this workload map, optimization becomes guesswork. Teams improve the query that is easiest to see rather than the path that creates the most operational cost.
A database should be evaluated in the context of the application around it. The same request may be harmless once and damaging when it is repeated for every item on a page or triggered by several connected services.

Product growth creates new query habits

Early applications usually support a small set of direct actions: create an account, save an order, retrieve a profile. As the product matures, teams add search, filters, audit views, exports, recommendations, internal dashboards, and automated workflows.
Each feature asks the database a new type of question.
A customer-facing screen may require low latency for one record. An operations dashboard may need the latest state of thousands of records. A finance report may reconstruct activity across an entire month. A notification job may repeatedly search for items that meet a changing condition.
These requests often arrive gradually, so no single feature appears responsible for the slowdown. The combined workload changes the character of the system.
Performance planning should therefore be part of product planning. A new feature is not only a user interface and business rule. It introduces a read pattern, a write pattern, and often a new expectation about freshness.

A drifting data model makes every request harder

Products evolve faster than their schemas. Teams add optional fields, reuse generic tables, and represent new relationships through conventions because changing the structure feels risky.
Over time, simple business questions become difficult to express. The application must interpret several columns, account for legacy values, and join records that were never designed to work together. Queries become longer, but the deeper issue is semantic complexity.
A slow request is sometimes a signal that the data model no longer matches the business. Adding indexes or caching may reduce response time temporarily, but the team will continue paying for ambiguity in every new feature.
Redesign is more expensive than tuning, so it should not be the first reaction. However, teams should recognize when optimization is protecting an obsolete structure rather than improving a sound one.

Reporting and transactional work need different treatment

The main product database is designed to support current operations: place an order, update a profile, assign a task, confirm a payment. Reporting asks broader historical questions and often reads much more data.
When both workloads run in the same place without boundaries, they can interfere. A large export or dashboard refresh may slow customer-facing actions. Teams then limit reporting, run jobs at inconvenient hours, or create unmanaged copies of production data.
A more deliberate architecture separates responsibilities. Operational data can flow into a reporting store, warehouse, or controlled replica designed for analysis. This does not need to be an elaborate big-data platform. The important point is that long-running analytical questions should not surprise the system responsible for immediate product actions.
Clean identifiers and consistent event timestamps make this separation far easier. If the operational model has unclear states, the reporting layer will reproduce that uncertainty at a larger scale.

More infrastructure cannot compensate for unlimited work

Increasing compute, memory, or storage can be a reasonable response to growth. It creates time and may be the most economical decision for a well-designed system.
The danger is treating capacity as the only variable. If one page makes dozens of redundant requests, a larger server allows the inefficiency to continue at a higher cost. If a background job scans the full history every few minutes, growth will eventually catch up again. If expired data is never archived, every operation must navigate an increasingly large active set.
Capacity planning and workload reduction should happen together. Teams need to understand what useful work the database performs and which work is repeated, poorly timed, or no longer necessary.

Indexes are helpful, but they are not a strategy

Indexes are one of the first tools teams reach for when a query is slow. They can dramatically improve the right access pattern. They also consume storage, increase the cost of writes, and require maintenance.
Adding an index without understanding the workload can shift the problem rather than solve it. A system with many indexes may read quickly but write slowly. An index designed for one filter may not help another. Unused indexes continue to impose cost.
The broader lesson is that performance work should be evidence-led. Teams need measurements that show which operations are slow, how often they run, what resources they consume, and how behavior changes over time.
Optimization based on production patterns is more reliable than tuning around one demonstration query.

Data lifecycle is a performance decision

Many databases treat every record as permanently active. Completed orders, expired sessions, old notifications, historical logs, and discontinued catalog items remain in the same operational paths as current information.
This increases more than storage. Routine queries may scan larger ranges, backups take longer, maintenance becomes heavier, and developers become cautious about structural changes.
A data lifecycle defines when information is active, archived, aggregated, or deleted. The rules should reflect legal, analytical, and business requirements. Some records must remain accessible for years. Others can be summarized or removed after a short period.
Lifecycle planning should happen before the database becomes difficult to manage. It is easier to preserve useful history when the organization knows why it is retaining each category of data.

Observability should connect technical symptoms to user actions

A dashboard that shows high database load is useful, but it does not explain which product behavior created it. Teams need a path from the technical signal to the user request, background job, or release that caused the change.
Useful monitoring connects response times, query patterns, resource use, error rates, lock or queue behavior, and data growth with application-level actions. Trends matter as much as incidents. A request that becomes slightly slower each month may deserve attention before it crosses an alert threshold.
Release comparison is especially valuable. When a deployment changes database behavior, the team should be able to see which endpoints or workflows increased their cost.
Performance is easier to manage when it becomes part of ordinary product feedback rather than an emergency topic reserved for outages.

Optimization needs a priority order

Not every slow operation deserves the same response. Teams should consider frequency, user impact, business importance, and growth trend.
A query that takes several seconds but runs once during a weekly internal report may be less urgent than a smaller delay repeated on every customer page. A background process that is acceptable today may deserve early work if its cost grows with the full history. A critical payment action may require stricter guarantees than an optional recommendation.
A practical sequence is:

Identify the highest-impact workload.
Confirm that the measurement reflects real production behavior.
Remove redundant or unnecessary requests.
Improve the query and access path.
Review whether the schema fits the business question.
Separate incompatible workloads.
Add capacity when useful work genuinely requires it.
Measure the result and watch for side effects.

This order avoids replacing architecture before simpler changes are tested, while still leaving room for structural redesign when it is justified.

External support should investigate before rebuilding

Organizations may use database development services when performance issues span schema design, application access patterns, migration, integration, and long-term scaling. The most valuable engagement begins with diagnosis rather than an immediate recommendation to move technologies.
A capable team should examine workload patterns, growth, data relationships, reporting needs, failure history, and operational constraints. It should distinguish configuration problems from application behavior and structural limitations.
The proposed solution may involve targeted optimization, a read replica, archiving, revised data flows, schema changes, or a staged migration. The right answer is the smallest change that creates a durable improvement without hiding a deeper problem.

Performance is an ongoing product property

A database is not optimized once. New features change its workload, customer behavior changes the distribution of data, and integrations introduce new access paths. A healthy system has a process for reviewing those changes.
Teams can include database impact in feature design, set performance budgets for important actions, review slow workloads regularly, and test migration or archival procedures before they are urgently needed.
This turns performance from a reactive infrastructure concern into a shared engineering and product responsibility.

Conclusion

Fast-growing products rarely wake up with a slow database for one reason. The slowdown is usually the history of how the product learned to use its data.
Traffic reveals inefficient access patterns, model drift, competing workloads, and absent lifecycle rules. Solving the problem requires more than adding resources or applying isolated fixes. Teams need to understand which business actions create database work and whether the current structure still supports those actions clearly.
The best performance strategy is continuous alignment between the product, its data model, and the way information is read, changed, retained, and analyzed.

Web3 App Development: How Modern Decentralized Applications Are Built in 2026

Mick Michaels — Tue, 25 Aug 2026 16:24:56 +0000

Web3 app development has moved well beyond the early model of connecting a frontend to a smart contract and asking users to manage every blockchain interaction themselves. Modern applications can sponsor gas and bundle several actions into one transaction. Smart-account infrastructure also makes recovery and more familiar authentication possible.
The underlying principle, however, has not changed: blockchain should be used where users benefit from verifiable ownership or shared execution. Everything else should make the product faster and easier to use. That balance is what separates a practical Web3 application from a conventional app with blockchain added on top.

What modern Web3 app development involves

A Web3 application usually combines decentralized and conventional software. Smart contracts handle the rules that need on-chain verification, while the surrounding application deals with the parts that benefit from speed and flexibility.
This hybrid approach has become increasingly important as Web3 products target audiences beyond experienced crypto users. Account abstraction is a good example of that shift. ERC-4337 infrastructure has already supported more than 26 million smart accounts and over 170 million UserOperations, showing how programmable account models are becoming a real part of application architecture.

Smart contracts define the trusted layer

Smart contracts are most useful for rules that should not depend entirely on one company’s private database. They can establish who owns an asset or define how value moves after a condition is satisfied. Other applications can then verify the same on-chain result.
This does not mean the entire application belongs on-chain. A social feed or frequently changing interface state may gain little from permanent blockchain execution. Good Web3 app development keeps the trusted layer focused, which reduces transaction costs and leaves the rest of the product easier to evolve.

Programmable accounts improve Web3 UX

Traditional Web3 onboarding often assumes that every user has a wallet and understands gas. That assumption is becoming less necessary.
ERC-4337 enables smart accounts with programmable validation and paymasters that can cover transaction fees. EIP-7702 extends the account model further by allowing an existing externally owned account to delegate execution to smart contract code. This can support batching and gas sponsorship without forcing the user to abandon the same address.
For product teams, this changes the design question. Instead of building around one signature for every blockchain operation, a Web3 app can increasingly organize several actions around the result the user is trying to achieve.

The backend still has an important role

Decentralization does not remove the need for application infrastructure. A backend can index blockchain events and prepare notifications. It may also deliver data to the interface much faster than reconstructing complex state directly from the network on every request.
The important distinction is authority. If ownership is defined on-chain, an indexed database should make that information easier to access without becoming a competing source of truth. When the indexer falls behind, the application should recognize that state instead of showing outdated information as final.

How Web3 app development works

A reliable development process starts with the product rather than the blockchain. The team first decides what users need to accomplish and where decentralized execution changes the result in a meaningful way.
Only then does it make sense to choose a network or design contracts. This order reduces the chance of building around Web3 features that later turn out to add more friction than value.

Step 1. Define the Web3 value proposition

The first stage identifies why the application needs Web3 at all. A marketplace may need verifiable asset ownership. A financial product may depend on transparent settlement. Another application may use blockchain to coordinate actions between participants who do not share one database.
The definition should be specific. “We want decentralization” is not enough to design an application around. A stronger requirement explains what users can verify or control because blockchain is present. That becomes the foundation for deciding what should eventually move on-chain.

Step 2. Design the on-chain and off-chain boundary

Once the value proposition is clear, the architecture can divide responsibilities between smart contracts and conventional software.
Contract logic should contain the rules whose integrity users need to verify. Supporting services can handle higher-frequency operations that do not need permanent blockchain execution. This usually creates a more practical system than pushing every product action on-chain.
Data design belongs in the same step. Public blockchain state should not become the default location for information that needs privacy or frequent modification.

Step 3. Choose the network and account model

Network selection should follow the workload. Transaction frequency may make fees a central concern, while a DeFi product may care more about access to existing liquidity. The ecosystem of wallets and developer infrastructure also affects implementation.
The account model is equally important. A crypto-native product may work well with existing external wallets. A mainstream application may need smart-account capabilities that reduce dependence on seed phrases and native gas tokens.
In 2026, Ethereum builders can work with both ERC-4337 and EIP-7702-based account flows. Current guidance encourages application developers to request wallet-level outcomes such as batched calls rather than tightly coupling the product to one low-level account implementation.

Step 4. Build contracts and the application together

Smart contract development should not happen in isolation while the frontend waits for a finished ABI. Contract behavior determines what users have to approve and how many transactions a workflow requires.
Developing both sides around the same user journey exposes these issues earlier. If a simple action needs three signatures, the team can reconsider the contract or account architecture before that behavior becomes deeply embedded in the product.
Events should also be designed with the application in mind. They give the indexing layer a structured way to recognize important state changes after a transaction confirms.

Step 5. Test the complete Web3 flow

A smart contract may pass its unit tests while the finished application still fails under real usage. Web3 testing should therefore follow complete user journeys.
The team needs to check what happens when a transaction is rejected or remains pending. Network changes need coverage as well. If gas sponsorship is part of the product, the fallback behavior should be clear when sponsorship is unavailable.
Testing account abstraction requires another layer because bundlers and paymasters become part of the execution path in ERC-4337 systems. The standard includes simulation and validation rules specifically because a UserOperation has to be checked before it can enter a bundle.

Key architecture decisions in Web3 development

Two Web3 apps can use the same blockchain and still have completely different architectures. The difference often comes from how much responsibility the team gives to smart contracts and how deeply blockchain mechanics appear in the interface.
These decisions should be made around the product’s trust model, not around a desire to maximize decentralization.

Single-chain and multichain architecture

Starting on one network usually creates a simpler product. Contract addresses remain easier to manage and users do not need to understand where an action is taking place.
Multichain architecture becomes useful when the application genuinely needs users or liquidity from several ecosystems. At that point, the challenge is not simply deploying the same contracts twice. State may need to move between networks, which introduces delays and more complicated failure states.
A cross-chain application should therefore define which network is authoritative for each piece of important state. The team also needs a response for cases where one side completes an operation while another side is temporarily unable to continue.

Wallet connection vs. embedded account experience

A connect-wallet flow works well when users already understand Web3. It gives them direct control and lets the product rely on wallet infrastructure that already exists.
Embedded or smart-account experiences can reduce that initial barrier. Gas sponsorship is one example: the application can pay transaction fees so a new user does not need ETH before completing the first action. Ethereum’s current gas-sponsorship guidance explicitly presents this approach as a way to reduce onboarding friction while users still authorize actions cryptographically.
The choice should reflect the audience. A professional DeFi terminal and a mainstream consumer app should not automatically use the same onboarding model.

Preparing a Web3 app for production

A successful testnet build is not the end of Web3 development. Mainnet introduces real assets and unpredictable usage. External infrastructure also becomes part of the product’s operational risk.
Production readiness therefore includes deployment discipline and monitoring alongside conventional software release work.

Security must cover more than smart contracts

Smart contracts deserve deep testing because deployed logic may be difficult to change. Still, the rest of the stack needs equal attention.
A compromised frontend can direct users toward the wrong action even when the contract itself is secure. Weak administrative access can expose privileged functions. An unsafe account-delegation design can also give code far more control than users realize; current EIP-7702 guidance treats delegation code as a major security boundary for this reason.
Security review should therefore follow the complete transaction path from the user interface to the on-chain result rather than ending at the smart contract repository.

Monitoring should connect blockchain and application state

Production monitoring needs visibility into what happens on-chain and what users see in the application. Contract failures are one signal, but delayed indexing can create a different kind of incident where the blockchain is healthy and the interface is wrong.
The team should also watch external infrastructure that the product relies on. Account-abstraction systems may depend on bundlers or paymasters. Multichain products introduce additional messaging dependencies.
A Web3 application becomes much easier to operate when these components are monitored as one system rather than separate technical services.

Conclusion

Web3 app development in 2026 is less about making every feature decentralized and more about choosing the right place for decentralized execution. Smart contracts provide the trusted layer, while modern account infrastructure can make interacting with that layer much less demanding for users.
The development process should begin with the product value and define the on-chain boundary before network selection or contract implementation. From there, account design and application integration can evolve together. When security and production monitoring are treated as part of the same architecture, Web3 becomes a practical product capability rather than an extra layer of blockchain complexity.