MongoDB was one of the platforms that helped me get apLabs moving quickly.
This is important, because early in a project you often need a tool that is easy to start with, forgiving while the design changes, and accessible enough that you can learn by building.
MongoDB Atlas Free Tier did exactly that for me. It gave me a practical way to explore the platform, build a working system, and learn how a document database behaves under real use without taking on infrastructure work or cost too early.
That is a generous on-ramp for developers, and in my case it worked perfectly.
The problem came later, when the project reached a point where the main issue was no longer learning the platform or shaping the data model. As the database grew, the issue shifted to performance.
solving the constraint that was actually in the way
This article is not really about databases. I wanted to highlight a common technical leadership mistake: treating every slowdown as a reason to spend more on the current setup instead of checking whether the setup itself is the bottleneck.
In my case, apLabs was still evolving, but the immediate friction was simple. The hosted environment had become too slow for the way I was now using the system. Once that happened, the right question shifted from, “Is MongoDB a good fit?” towards, “What is causing the performance drag, and what is the simplest sensible way to remove it?”
Initially I misdiagnosed the reason for the performance slowdown. After a weekend with CoPilot optimising razor pages I had exhausted most options to further streamline the code. Then I ran a database backup, and what previously took 5 minutes took over 20 minutes. The constraint turned out to be self-hosting MongoDB Community Edition on shared infrastructure – something had changed. It had worked perfectly for nearly a year, but was not controlled by me so it was convenient to ignore it. I found out about the hosting change the hard way.
Why MongoDB was still the right database
Before getting to the hosting discussion, it is worth saying clearly that MongoDB itself was not the problem.
apLabs is still a changing system. New document types appear. Existing records pick up new fields. Relationships between tasks, projects, notes, and conversations become clearer as the application is used. MongoDB suits that kind of work well because its document model allows the structure to evolve without forcing a lot of early schema design.
MongoDB’s own documentation makes this point directly: the flexible schema supports iterative data modelling as an application develops. That perfectly matched what I needed while building and refining apLabs. I could start small, change the model as I discovered what really mattered, and avoid spending too much time locking down structure too early.
So the database choice still made sense.
The hosting decision was the part that had to evolve.
Atlas Free Tier was valuable, and then it became the limit
I want to be fair to MongoDB Atlas Free Tier, because it was useful.
For a developer getting started, it is a very good offer. MongoDB provides a free managed path with no credit card required, which lowers the barrier to entry considerably. According to MongoDB’s published information, the M0 free tier includes 512 MB storage, runs as a shared cluster, and is intended for learning, prototyping, and early development. That is exactly how I used it.
It helped me learn the platform. It helped me test ideas quickly. It removed operational overhead while the project was still immature.
But free tiers are there to help you start, not to carry every workload indefinitely. Atlas documentation is clear that M0 is a shared environment with limits on throughput, connections, and other features. For example, MongoDB publishes limits such as shared compute resources, 500 concurrent connections, and request-rate limits on the free tier. Those limits are reasonable for its intended purpose. They are part of what makes the free offering possible.
Over time, though, my system became sluggish enough that the hosting tier itself had to be re-evaluated.
The weekend decision
Over a weekend, performance dropped far enough that it was getting in the way of normal work.
At that point I had a few obvious options:
- bite the bullet and move to a paid Atlas tier
- tolerate the slowdown for a while while continuing to spend CoPilot credits on code optimisation
- move the database to a self-hosted environment
For a customer-facing production system, the first option would often be the sensible one. Throw dollars and upgrade the subscription tier. Managed services earn their keep. They reduce operational burden and give you a cleaner platform for reliability, security, and support.
But apLabs is still an internal R&D system. At this stage, paying more each month was not the most attractive answer, especially when I already had a small Debian server running locally with Portainer in place.
That made the third option much simpler than it might sound.
MongoDB Community Edition is available through MongoDB’s official Docker image, and MongoDB documents container-based installation as a supported route for quick deployment and testing. In my case, this meant I could stand up a local instance without turning the exercise into a full infrastructure project.
So that is what I did. It took less than 2 hours.
What changed after moving to self-hosted MongoDB
Once apLabs moved from Atlas Free Tier to a self-hosted MongoDB Community container, the performance issue eased immediately in my environment. The application is flying!
I am deliberately stating that as an observation, not as a benchmark claim. I am not arguing that self-hosted MongoDB is always faster than Atlas, or that managed hosting is somehow inferior. That would be too broad, and it would miss the point.
My learning is narrower and more practical:
I had a workload that no longer suited the free shared tier, and I had local infrastructure that could handle it comfortably. Moving the database solved the specific problem in front of me.
A constraint that had been worsening for nearly a year suddenly evaporated. I should have seen this sooner and anticipated it, but I was blinded by the excitement of adding feature after feature until the system ground to a halt.
separate the platform from the packaging
Technical teams often conflate the tool with the way the tool is being consumed. When that happens, a performance problem gets interpreted as a problem with the technology itself. It is easier to blame the database technology when what is really constraining is the way it has been deployed.
That is flawed thinking, but it is easy to fall into this trap when under time pressure.
MongoDB was still a good fit for apLabs. What stopped fitting was the free, shared hosting tier. Once I separated those two facts, the path forward became much clearer.
That framing helps in other situations too:
- a database may still be the right choice even if the entry-level hosted plan is no longer enough
- a cloud tool may still be a good architectural choice even if the pricing tier is poor value for your current workload
- a self-hosted move can be a practical intermediate step, not a grand anti-cloud statement
In other words, you do not always need a new stack. Sometimes you just need a better home for the current one.
The trade-off: you solve one constraint and accept another
Self-hosting is never free in the real sense.
You may lower direct subscription cost and improve responsiveness, but you also take on operational responsibility. Backups, monitoring, upgrades, storage management, recovery planning, and security hardening become your problem.
That is manageable if the system is internal, the scale is modest, and you are deliberate about the trade-off. It is much less attractive if you are supporting a business-critical external application and need strong guarantees around resilience and support.
So I would not turn this into a universal recommendation. I would describe it more carefully:
- If a free managed tier helped you learn and get started, that is a success.
- If the next bottleneck is performance, the next step may be moving the platform to something you manage on your own hardware.
- If the next bottleneck after that is operational risk, managed hosting will likely become attractive again.
That is a healthier way to think about technical maturity.
A second cost pressure is emerging: AI tooling itself
There is a more serious parallel issue developing for software teams right now.
For the last few years, many developers have become used to paying a flat monthly price for premium AI assistants. That model is starting to shift. Recent vendor changes suggest that AI coding and assistant tools are moving toward harder usage caps, credit-based consumption, or explicit overage pricing for heavier workflows.
One example is GitHub Copilot’s announced move, from June 2026, toward usage-based AI credits for premium features rather than the old assumption of effectively unlimited premium access within a flat subscription. Other tools in the coding-assistant market are also experimenting with tighter quotas, credits, or capped premium usage. The details vary by vendor, but the direction is becoming clearer: heavy users may need to watch cost much more carefully.
That does not mean cloud AI is going away. It does mean developers may need to think more deliberately about where expensive frontier models are truly justified, and where smaller or self-hosted models could do part of the job more economically.
Our technical teams are about to run headlong into the next constraint of AI assisted development – the cost of agentic coding tasks. Like my MongoDB free tier, the party is ending and the hard reality of the economics of AI agents will hit developers hard.
Practical self-hosted LLM alternatives for developers
For developers who want to reduce dependence on expensive frontier subscriptions, there are now several serious local or self-hosted options worth watching.
A sensible way to think about them is by use case.
1. Ollama for simple local model workflows
If the goal is to get a local model running quickly on a workstation or small server, Ollama is probably the easiest place to start. It has become popular because it gives developers a straightforward way to pull and run open-weight models with minimal setup.
Why it matters:
- easy local setup
- good for experiments, private drafting, and lightweight coding help
- works well when one developer wants a personal local model endpoint
Best fit:
- solo developers
- laptop or workstation use
- fast evaluation of smaller coding and reasoning models
2. llama.cpp for efficient local inference
llama.cpp remains one of the most important building blocks in the local-model ecosystem. It is well suited to running quantised models efficiently on modest hardware, including mixed CPU/GPU setups.
Why it matters:
- strong performance on constrained hardware
- broad support across open models
- good for developers who want control and efficiency
Best fit:
- technically hands-on users
- edge devices or smaller local machines
- private inference without a heavyweight serving stack
3. vLLM for more serious internal serving
If the use case shifts from “my local assistant” to “a shared internal model service,” vLLM becomes more relevant. It is designed for higher-throughput serving and is better suited to internal platforms where multiple users or tools may call the same model.
Why it matters:
- built for serving models at scale
- better for internal APIs than desktop tooling
- useful if self-hosted AI moves beyond experimentation
Best fit:
- team environments
- internal AI platforms
- private higher-volume inference
4. Smaller open coding models for targeted developer workflows
The strongest practical case for self-hosted AI is not usually “replace every frontier model.” It is “use smaller models where they are good enough.”
Current open model families developers may want to evaluate include:
- Qwen coder variants for coding and general development tasks
- DeepSeek coder-style models and successors for code-heavy work
- StarCoder2 for transparent open development use cases
- Devstral / Mistral developer-oriented models for software engineering assistance
The exact leader will keep changing, so I would avoid hard claims that one model is universally best. The more durable point is this: the open-weight ecosystem is improving quickly, and for many drafting, summarising, repo navigation, and code explanation tasks, a smaller specialised model may now be good enough.
I have no experience with these alternative LLM recommendations. But this will start to matter if costs keep rising. Like my use of cheap hosted MongoDB needed to be challenged, we might be reaching the point where large expensive AI data centres cost more than cheap, fit for purpose models hosted on your own hardware.
A practical decision rule for developers
For both databases and AI tooling, the same principle applies:
- start with the easiest path that helps you learn,
- then upgrade only when the real constraint becomes clear.
MongoDB Atlas Free Tier was a good place to begin. It helped me learn the platform and build the application without premature infrastructure work. When performance became the issue, self-hosting MongoDB Community Edition was the better fit for the stage apLabs had reached.
The same mindset may soon apply to AI tooling. Premium hosted models will still have a place, especially for demanding reasoning and broad capability. But when subscription caps tighten and overage pricing becomes more visible, many developers will have a reason to look harder at local, specialised, self-hosted options.
Conclusion
The most useful lesson from this MongoDB move is fairly modest, but I think the underlying principle has immediate application to the next obstacle – high costs of AI assistants.
- Cost and performance are related. A free tier can be fit for purpose to get started.
- A platform can remain the right one even when the costs surge and become unaffordable for you.
- A technical decision can improve simply by identifying the real constraint and not simply throwing more money at the problem.
In apLabs, MongoDB helped me get started. Self-hosting is helping me keep momentum. One day I will likely return to managed hosting when the system outgrows my Portainer environment.
References
- MongoDB. “Data Modeling in MongoDB.” Accessed 21 May 2026. https://www.mongodb.com/docs/manual/data-modeling/
- MongoDB. “Install MongoDB Community Edition with Docker.” Accessed 21 May 2026. https://www.mongodb.com/docs/manual/tutorial/install-mongodb-community-with-docker/
- MongoDB Atlas documentation and pricing pages describing M0 free tier characteristics and limits, accessed 21 May 2026.
- GitHub blog and pricing updates regarding Copilot usage-based AI credits effective June 2026, accessed 21 May 2026.
