A lot of AI demos look impressive because they solve the easy part: getting a plausible answer from a small example.

The harder part comes later. How do you load the data reliably? How do you test the retrieval pipeline? How do you version the data? How do you handle access control, governance, and domain-specific terminology? How do you know that the system is still working next month, not just in today’s demo?

That is where the database choice starts to matter. A dedicated vector database may be excellent for fast experimentation, especially for pure semantic search. But if your company already has mature relational data, existing governance processes, and a team comfortable with SQL, jumping straight into a new vector database may create more complexity than value.

For many AI use cases, the best first step is not “add another database”. It is “look at what your current database can already do”.

That is less exciting than demo-ware, but much closer to production reality.

Read the article: https://mkdev.me/posts/which-database-when-for-ai-vector-and-relational-databases-in-practice

In this practical video, we deploy an HTTP-triggered Google Cloud Function using GitHub Actions instead of the UI or gcloud.

Push to main, run the pipeline, deploy the function, test it with curl.

Watch the video to see the full workflow: https://www.youtube.com/watch?v=B2VhvYZDXvM

In the 94th mkdev dispatch Kirill discusses the short rise and the quick fall of AI browsers development: https://mkdev.me/posts/ai-browsers-are-dead-94

There is no universal winner between Terraform and Pulumi.

For many companies, Terraform is still the safer default. It is familiar, widely adopted, easy to hire for, and well suited for teams that want infrastructure described in a predictable declarative format.

Pulumi shines in a different situation: when your infrastructure logic becomes too awkward to express cleanly in HCL. If you need complex conditionals, loops, reusable abstractions or developer-style testing, using a real programming language can be a big advantage.

But that advantage only matters if the team maintaining the infrastructure is comfortable with that language. Otherwise, you may just move the complexity from HCL into Python or TypeScript.

That is the real decision: not “which tool is better?”, but “which tool matches the way this team actually works?”

We covered the trade-offs in this article: https://mkdev.me/posts/should-you-use-terraform-or-pulumi

No two data science projects are the same.

mkdev works with your team to understand the problem, shape the right approach, and build a solution that fits your business. Check out the page and schedule a call: https://mkdev.me/b/consulting/data-science

AI output can be dangerously convincing because it often looks like the product of understanding.

A well-written answer feels intelligent. A clean summary feels reliable. A generated image feels intentional. A code snippet feels like it came from someone who knows the system. But the Generative AI Paradox shows why this impression can be misleading: models may create strong outputs without having the kind of understanding we usually associate with creation.

This distinction matters more in 2026 than it did two years ago. AI is now closer to daily business processes, internal knowledge bases, customer support, software delivery, and decision-making workflows. The cost of a wrong answer is no longer just a funny screenshot. It can become a broken process, a compliance issue, or a bad business decision.

So the real AI maturity question is not “are we using the latest model?” It is “do we know where the model fails, and have we built the system accordingly?”

https://mkdev.me/posts/is-ai-really-intelligent-the-generative-ai-paradox

Before adding another cost optimization platform, it’s worth understanding what AWS already gives you out of the box.

This article walks through Cost Explorer, AWS Budgets and Trusted Advisor, and how they help spot waste before it grows.

Read it here: https://mkdev.me/posts/built-in-aws-tools-for-cost-analysis-and-optimization

Understand containers without relying on Docker as the starting point. Learn how OCI defines container standards and discover what actually happens when we build, run, and manage containers.

Video: https://www.youtube.com/playlist?list=PLozcbFx8FoPH30kYPbPuPsvxASWoLo9XB
Articles: https://mkdev.me/posts/what-s-wrong-with-docker-introduction-to-the-dockerless-course

There is a cost and complexity tradeoff when protecting Cloud Run applications.

Cloud Armor gives you native Google Cloud protection, WAF rules, DDoS protection, and tight integration with load balancing. But it also means setting up the right load balancer path and understanding the pricing model.

For some teams, that is absolutely the right choice. For others, especially smaller projects, an external layer like Cloudflare may be simpler or cheaper enough to consider.

The decision should not be “Cloud Armor or nothing.” It should be: where is traffic entering, what threats do we actually need to mitigate, can the protection be bypassed, and what does the monthly cost look like once the architecture is real?

That is the part teams often miss when moving from “Cloud Run works” to “Cloud Run is production-ready.”

https://mkdev.me/posts/can-i-use-cloud-armor-with-cloud-run

AWS has too many moving parts for guesswork: IAM, S3 costs, EKS vs ECS, Lambda, EC2, monitoring, migrations. mkdev’s in-depth AWS audit helps you find what to improve and what to rethink. Check out the page and schedule a call: https://mkdev.me/b/audits/in-depth-aws-audit-and-assessment

A lot of AI discussions still jump too quickly to tools: which model, which vector database, which agent framework, which platform.

Those decisions matter, but they are not the starting point. The mkdev AI strategy guide makes a more practical point: before big platform choices, a company needs a management sponsor, the right AI talent, and a clear view of how hard the problem is from the business, data, and AI perspectives.

That is a very useful filter for 2026. The AI market is louder than ever, and every vendor has a story about productivity, automation, and agents. But if the problem is poorly scoped, if the data is not ready, or if the technical metric has no connection to a business KPI, the project can look impressive and still create very little value.

AI strategy should help companies decide what to build, what to buy, what to postpone, and what not to do at all.

That last part is underrated.

https://mkdev.me/posts/ai-strategy-guide-how-to-scale-ai-across-your-business

Cloud security often fails in the basics: unclear responsibility, excessive access, missing encryption, weak logging, and untested incident response.

This checklist breaks it down into 7 practical steps for reducing risk: https://mkdev.me/posts/cloud-security-checklist-7-essential-steps

Practical cloud work is always easier to explain through real projects. Our case studies show how mkdev helped teams with identity management, cloud infrastructure, AWS cost optimization, Kubernetes decisions and more.

Read them here: https://mkdev.me/b/cases

Many backend bugs are not caused by bad SQL syntax. They are caused by perfectly valid SQL running concurrently.

Two transactions can read the same row, calculate new values, and write back results that silently overwrite each other. Another transaction can re-run a query and see a different set of rows. A group of transactions can commit successfully, but still produce a result that could not happen if they had run one after another.

This is why transaction isolation levels matter. PostgreSQL gives you several tools here: the default Read Committed, stronger Repeatable Read, strict Serializable, and explicit locks when you need more control.

The catch is that stronger isolation may mean more retry logic and different performance characteristics. You do not need to use the strictest level everywhere, but you do need to understand what guarantees your code actually relies on.

We covered the main isolation levels and common anomalies in this article: https://mkdev.me/posts/transaction-isolation-levels-with-postgresql-as-an-example

From ETL pipelines and data lakes to warehouses, streaming, and cloud-scale infrastructure, mkdev helps teams make data available, organized, and ready for real business use. Check out the page and schedule a call: https://mkdev.me/b/consulting/data-engineering

A lot of GenAI discussions still focus on code generation. But for many data and AI teams, the bigger value is elsewhere.

The mkdev article points to a more practical pattern: GenAI helps teams search internal knowledge, draft requirements, create explanations for model recommendations, prototype faster and make expert knowledge easier to access. These are not always the most glamorous use cases, but they often remove real bottlenecks in how teams work.

That feels even more true in 2026. AI assistants can speed up parts of individual work, but faster output also creates new pressure on review, evaluation, governance and maintainability. The productivity question is no longer just “How much more can we generate?” It is “Can the organization absorb, verify and safely use what gets generated?”

For data and AI leaders, that is the real management challenge now.

https://mkdev.me/posts/how-genai-has-and-hasn-t-changed-the-way-allianz-thoughtworks-and-outbrain-lead-data-and-ai-teams

You can run data jobs in Jenkins. You can patch servers with Airflow. But should you?

This video breaks down how job execution systems work and how to think about choosing the right tool.

Watch it here: https://youtu.be/YjFbTNdXhQo?si=w8lcCQNg4N2XbltN

mkdev’s Helm Lightning Course is a practical introduction to Helm for people who already know the Kubernetes basics and want to understand how Helm actually helps in day-to-day deployments. It covers the core ideas behind Helm, including charts, releases, templates, values, upgrades, and rollbacks, using a simple pgAdmin example throughout the course.

It also goes beyond the basics with lessons on hooks, chart dependencies, ArtifactHub, and three useful Helm plugins: Helm Secrets, Helm Diff, and Helm Git. You can go through the course as articles here: https://mkdev.me/posts/why-do-you-even-need-helm, or watch the video version here: https://www.youtube.com/playlist?list=PLozcbFx8FoPHqL9Gm1IpboF45gekmgYjO. Use it for free and make your Kubernetes deployments easier to manage.

IAM policy generation is still one of the less glamorous parts of AWS work, but it matters a lot.

Too many applications run with permissions they don’t need because nobody wants to manually map every code path to every AWS API action. That’s understandable, but it’s also how small shortcuts become long-term risk.

IAM Access Analyzer gives you a native AWS path: analyze CloudTrail activity, generate a policy template, then review and customize it. ActionHero gives you another angle: observe the SDK calls your app makes and use that as input for a tighter policy. Both approaches have limitations, but they move the conversation from “what do we think this app needs?” to “what did this app actually try to use?”

That shift is still very relevant in 2026.

Read the article here: https://mkdev.me/posts/how-to-create-aws-iam-policies-with-actionhero-and-access-analyser

Not sure if your Google Cloud setup is still the right fit for your workloads?

mkdev’s GCP Audit reviews your infrastructure from security and cost to availability, automation and DevOps practices.

Check out the page and schedule a call: https://mkdev.me/b/audits/google-cloud-platform