Building with Purpose: The Tech Stack Behind My Database PAM Solution
In my previous posts, I shared my frustration with existing PAM solutions and outlined the architecture I'm building to fill those gaps. Today, I want to get into the nuts and bolts of the technology choices I've made.
My North Star: Getting Shit Done
Before diving into specific technologies, let me share what drives my technical decisions. After years of building software, I've realized something critical about myself: I value productivity and forward momentum above almost everything else. The best tech stack for me is one where I spend 90% of my time actually building and 10% reading documentation - not the other way around.
When choosing technologies for this project, my priorities were clear:
- Speed of development (this is a solo project with real-world deadlines)
- Ease of deployment (because security tools should be accessible)
- Maintainability (because abandoned security tools create vulnerabilities)
- Appropriate performance (not theoretical benchmarks, but real-world usage)
- Security features (obviously critical for a PAM system)
With that framework in mind, let's dive into the specific choices.
Frontend: SvelteJS - Love at First Compile
I still remember the moment I fell in love with Svelte. I had been struggling through React and Angular projects, getting lost in endless configuration debates, state management options, and component design patterns. It felt like I was spending more time reading about React than actually using it.
Then I did a quick POC with Svelte, and it was like someone had removed a weight from my shoulders. Suddenly I was just... writing code. Building features. Making progress.
What Svelte gets right is simplicity without sacrificing power. The framework gets out of your way and lets you focus on what you're building rather than how the framework works. The compiler-based approach means less boilerplate, less runtime overhead, and ultimately a better developer experience.
I've tried the React and Angular paths. They're fine for todo apps when you're following a tutorial, but the moment you try to build something real, you're down a rabbit hole of:
- "Which state management library should I use?"
- "What's the best way to handle forms?"
- "How do I optimize renders?"
- "Why is my bundle size so large?"
With Svelte, these questions either don't come up or have clear, straightforward answers. I spend my time building product features, not debating abstract framework concepts.
Could I have used Vue? Probably. But Svelte just clicked for me, and when you're building something ambitious, that connection with your tools matters.
Backend: Laravel - PHP Without Apology
Let me say something controversial in tech circles: PHP is a practical, productive language for building web applications, and I'm not apologizing for using it.
After evaluating Java, Python, Go, and NodeJS, I landed on PHP with Laravel for very specific reasons:
Productivity Is King
PHP frameworks have evolved significantly over the years, learning from the best patterns in other ecosystems. The result is frameworks like Laravel that offer exceptional developer productivity.
The ecosystem provides:
- Code generation and scaffolding that actually works
- An ORM (Eloquent) that makes database interactions both safe and intuitive
- Authentication and authorization systems built for real-world use cases
- A queue system that handles background processing elegantly
These aren't just nice-to-haves - they're critical for building a comprehensive security system efficiently.
The Java Spring Boot Detour
I spent weeks trying to convince myself that Spring Boot was the "proper" choice. It's enterprise-grade, right? It has all the security features, right?
But I found myself fighting the framework constantly. Everything felt unnecessarily complex and opinionated to the extreme. I'd spend hours just trying to get basic configurations working.
The tutorials I found were concerning too - so many demonstrated practices that made me cringe. Even worse, I found myself back in the same trap: 90% reading documentation, 10% actual coding.
The Python Problem
Python is a fantastic language for many use cases, but I've never felt comfortable with its syntax. The lack of brackets makes me anxious about code structure, and the documentation for many frameworks is surprisingly inconsistent.
Performance isn't my primary concern, but it's worth noting that PHP 8 with a modern framework can actually outperform Python in many web application scenarios.
Go: Great But Overkill
Go would offer impressive performance and deployment benefits, but for a CRUD-heavy application with complex authorization rules, it felt like the wrong tool. Building a PAM system in Go would mean:
- Implementing much more from scratch
- Less built-in security features
- Weaker ORM capabilities
- More manual work for standard web application tasks
For a specialized service handling heavy computational loads? Go would be fantastic. For this project? It would slow me down significantly.
Node/Express: Dependency Nightmare
Using JavaScript throughout the stack sounds appealing until you consider the security implications. The NPM ecosystem's dependency patterns create a massive attack surface - not ideal for a security tool that will handle privileged credentials.
TypeScript helps with many JS issues, but the ORM options still lag behind what PHP offers with Eloquent, and the code generation tools aren't as mature.
Why Laravel Specifically?
I've worked with Yii2 extensively, but Laravel offers a few key advantages for this project:
- More active community and ecosystem
- Better documentation (crucial for creating an open-source project others can contribute to)
- More security-focused packages and extensions
- A more intuitive authentication system
The decision wasn't about which language is "best" in some abstract sense - it was about which would let me build a secure, maintainable PAM system efficiently.
Database: MySQL - Simple, Stable, Sufficient
My database choice was less fraught. MySQL is a proven, stable choice that meets all my requirements. I considered SQLite for even simpler deployment, but ultimately MySQL's robustness won out.
The heaviest tables will be audit logs and session records, neither of which require exotic database features. MySQL provides everything needed while maintaining:
- Simple deployment options
- Broad hosting support
- Familiar administration
- Solid security features
- Excellent Laravel integration
Sometimes the obvious choice is the right one.
AI Integration: Google Gemini - Practical and Affordable
After testing ChatGPT, Gemini, and DeepSeek, I found Gemini provided the most consistent results for my specific use cases:
- Pre-request analysis
- Approval decision support
- Post-session audit reporting
The API pricing is reasonable for the expected usage patterns, and the integration process is straightforward. This decision isn't set in stone - post-MVP, I plan to make AI integration configurable so users can connect their preferred model.
Deployment: Docker for Accessibility
Containerization through Docker was an easy choice. It provides:
- Consistent deployment across environments
- Simplified installation for end users
- Reduced "it works on my machine" problems
- Easy updating mechanisms
For a security tool aimed at resource-constrained organizations, making deployment as frictionless as possible is crucial.
Secret Management: Still Exploring
The PAM system will need to securely store and manage credentials. I'm considering both HashiCorp Vault and Infisical as integration options, but this is one area where I'm still conducting POCs to determine the best approach.
I'm prioritizing:
- Open source availability
- Simple deployment
- Solid security practices
- Good API documentation
This will likely be one of the last features I implement, giving me time to thoroughly evaluate options.
The Real Point: Building What Works
Here's what I've learned after years of development: the "best" technology is the one that lets you build, ship, and maintain your specific application effectively. For me, with this project, that means prioritizing technologies that let me move quickly and confidently.
Could I build this system in Java or Go? Sure. Would it take three times as long and be more complex to deploy? Almost certainly.
When you're trying to democratize security - to make enterprise-grade protection accessible to teams without enterprise resources - pragmatism matters more than theoretical purity. Every month spent debating the perfect framework is another month that organizations remain vulnerable.
My goal isn't to win technology arguments on Twitter. It's to build a tool that makes database security accessible to more organizations. That north star guides every technology decision I make.
In my next post, I'll dive into the implementation details of the Just-in-Time access system and how it integrates with the approval workflow. Until then, I'd love to hear your thoughts on these technology choices or your experiences with similar projects.
Because at the end of the day, technology is just a means to an end. And my end goal remains clear: making robust database security accessible to everyone, not just those with massive security budgets.
Stay tuned for the next post in this series...