PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
“Stop using databases” is a call to stop operating the data infrastructure yourself—not to stop storing data or relying on database technology. In a 2021 interview and webinar, Patrick McFadin argued that application teams should consume data capabilities through managed services and simpler interfaces, such as APIs, instead of taking on every cluster, driver, and distributed-systems task. It is a viewpoint, not a rule for every organization: a service still has to fit the application’s data model, recovery needs, security requirements, portability expectations, and budget.
What “using data services” means
A database stores and organizes data. A data service makes that capability available through an interface an application can use, while a provider or separate service layer takes responsibility for some of the underlying infrastructure. The application still reads and writes data; the change is where operational work sits and how the application reaches the data layer.
In a June 2021 interview, McFadin described taking open-source database technology and offering it as a hosted service. He favored a simpler interface, such as HTTP APIs, over requiring every application team to manage database drivers and distributed-system operations. His examples included Cassandra, DataStax Astra, and Stargate, which he described at the time as an access layer over Cassandra. Those are examples from that conversation, not claims about current product status or capabilities.
Why McFadin made the argument
McFadin’s case was that operating a distributed database can demand specialist attention that many product teams would rather spend on application features. The interview discussed concerns such as sharding, driver setup, data models, and distributed coordination. A service abstraction can reduce the amount of infrastructure a team directly manages, but it does not remove the need to make sound data and architecture decisions.
#1 Best Overall
“And my philosophy as a technologist is that proper, really important technology like your data layer should just fade into the background and it’s just something you use, it’s not something you have to reason through very much.”
That was McFadin’s stated philosophy in the Serverless Chats interview, not a measured finding about productivity or a consensus recommendation. In the same 2021 conversation he said, “the era of running your own database is coming to an end. You should not run your own database.” Read that as a deliberately forceful opinion, not an established industry fact. The Linux Foundation webinar listing likewise framed cloud and Kubernetes as changing architecture decisions and said the event would discuss development speed, open source, community, and future-proofing; that promotional description does not establish measured outcomes.
What changes—and what does not
| Approach | Who operates the infrastructure | What the application team still needs to decide |
|---|---|---|
| Self-managed database | The organization operates the database infrastructure and handles its associated operational work. | Data model, queries and access patterns, performance, availability, security, backup and restore, and ongoing operating costs. |
| Managed data service | A provider operates database infrastructure and exposes a service interface; the exact division of responsibility depends on the service. | Whether the service fits the workload, what controls and recovery processes it offers, how data can be moved, and what it costs under actual use. |
| API or access layer over a database | A separate layer provides an interface to a database; this alone does not establish that the underlying database is hosted or operated by a provider. | How the layer maps to the database’s data model, which capabilities it exposes, and whether it creates dependencies or migration constraints. |
Even when a provider runs the infrastructure, an application remains dependent on stored data and the service’s behavior. Teams still need to understand the available data structures and query patterns, and to verify the service’s limits. An API can simplify how code reaches data; it cannot make an unsuitable data model suitable or guarantee portability between providers.
How to evaluate a data service for your workload
Compare the service with the self-managed alternative using a real application workload and a recovery scenario. The 2021 interview raises portability and lock-in, and mentions service-specific details such as access tokens and historical backup limitations for Astra at that time. Those details should not be carried forward as descriptions of current offerings.
- Assign operational responsibility. Identify who patches and upgrades the system, responds to incidents, and handles routine operations. Confirm which responsibilities remain with your team under the service’s current terms.
- Check workload fit. Map the application’s reads, writes, data model, and query patterns to the service’s supported capabilities. Include the latency and availability requirements that matter to the application.
- Walk through recovery. Determine how backups are made, who can initiate a restore, what the restore process requires, and how your team will test it. A backup feature is not a recovery plan until the process has been exercised.
- Review security and access. Establish how identities, permissions, and application access are managed, and verify that the controls meet your organization’s requirements.
- Test the exit path. Find out how data can be exported, what application changes a move would require, and whether the service interface ties the application to provider-specific features.
- Estimate full cost under actual usage. Compare the service’s charges with the infrastructure and people needed to operate a self-managed option. The interview supplies no current prices or comparable cost measurements.
When the shift may make sense
A managed service is worth considering when the team wants to reduce direct infrastructure work and the service demonstrably meets the application’s requirements. Self-management may remain appropriate when a team needs control the service does not provide, has a strong operational reason to run the database itself, or cannot accept the service’s recovery, portability, or economic trade-offs. Neither option is automatically better: the decision depends on responsibility boundaries and workload fit, not on the slogan.
Quick Recap
What the 2021 argument can—and cannot—tell you
The webinar was recorded March 17, 2021, and sponsored by DataStax; McFadin was identified as DataStax’s Head of Developer Relations at the time. The interview followed on June 7, 2021. These sources explain his rationale for shifting database operations behind services, but they do not establish current vendor capabilities, service guarantees, prices, performance, compliance status, or comparative savings. Check current provider documentation and terms before making a present-day product decision.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
