[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-database-indexing-slow-queries":3,"blog-nav-database-indexing-slow-queries":26},{"slug":4,"title":5,"description":6,"body":7,"category":8,"readTime":9,"tags":10,"coverImage":13,"coverImageAlt":14,"heroImage":15,"heroImageAlt":14,"metaTitle":16,"metaDescription":17,"ogImage":18,"noindex":19,"published":20,"publishAt":21,"sortOrder":22,"updatedAt":21,"status":23,"path":24,"bodyHtml":25},"database-indexing-slow-queries","Indexes: why a correct query gets slow as the table grows","A right query still gets slow when the planner reads the whole table. Read the plan, add the index that matches the filter, and leave unused indexes out.","The query was correct when the table had a few thousand rows. It is still correct at a few million. The planner stopped using a shortcut and started reading the table. That is an index problem, not a “the app is old” problem.\n\n[Why website speed affects revenue](\u002Fblog\u002Fwebsite-speed-affects-revenue) is about what the browser does: weight, LCP, the wait on a phone. A strong Lighthouse score does not index your bookings table. This article is the database time inside that wait.\n\n## What an index is for\n\nAn index is a side structure the planner can use to find rows without reading all of them. A filter on branch and start time wants an index that leads with those columns. An index on `created_at` does not help that filter just because it exists.\n\n[PostgreSQL’s index documentation](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Findexes.html) is the reference we use when the engine is Postgres. The habit is the same on MySQL: read the plan, do not guess. Which engine you are on is the earlier decision in [PostgreSQL or MySQL](\u002Fblog\u002Fpostgresql-vs-mysql-for-applications).\n\n## How you know\n\n`EXPLAIN` the statement that the slow screen actually runs. `EXPLAIN ANALYZE` belongs on a copy or a quiet window, not as a reflex against production during a sale.\n\nA sequential scan of a large table, for a filter that should return a handful of rows, is the smell. A scan of a 200-row settings table is fine. Indexing every column is how writes get slower: every insert maintains every index.\n\n## What we change\n\n1. Capture the statement from the slow screen or the slow-query log. Not a hunch about “the database.”\n2. Read the plan.\n3. Add the index that matches the filter and the sort.\n4. Confirm the plan changed.\n5. Drop indexes nothing uses.\n\nIf the plan is already an index lookup and the screen is still slow, the time is somewhere else: a chatty API, a missing cache, or the browser work in the speed article. Another index will not fix that.\n\n## Straight next step\n\nIf one named screen got slower after a year of real data, [send the query](\u002Fcontact). We will read the plan before anyone rewrites the page.","Performance",6,[11,8,12],"Database","SQL","\u002Fimages\u002Fjournal\u002Fdatabase-indexing-slow-queries-cover.webp?v=20261013b","Hand-drawn chart on a desk beside a ruler and pens","\u002Fimages\u002Fjournal\u002Fdatabase-indexing-slow-queries-hero.webp?v=20261013b","Why Queries Slow Down as Tables Grow | PrimeCode","How database indexes keep a correct query fast as rows grow, and when an extra index makes writes worse.","\u002Fimages\u002Fjournal\u002Fdatabase-indexing-slow-queries-og.webp?v=20261013b",false,true,"2026-10-12T01:00:00.000Z",50,"live","\u002Fblog\u002Fdatabase-indexing-slow-queries","\u003Cp>The query was correct when the table had a few thousand rows. It is still correct at a few million. The planner stopped using a shortcut and started reading the table. That is an index problem, not a “the app is old” problem.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"\u002Fblog\u002Fwebsite-speed-affects-revenue\" rel=\"noopener noreferrer\">Why website speed affects revenue\u003C\u002Fa> is about what the browser does: weight, LCP, the wait on a phone. A strong Lighthouse score does not index your bookings table. This article is the database time inside that wait.\u003C\u002Fp>\n\u003Ch2>What an index is for\u003C\u002Fh2>\n\u003Cp>An index is a side structure the planner can use to find rows without reading all of them. A filter on branch and start time wants an index that leads with those columns. An index on \u003Ccode>created_at\u003C\u002Fcode> does not help that filter just because it exists.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Findexes.html\" rel=\"noopener noreferrer\">PostgreSQL’s index documentation\u003C\u002Fa> is the reference we use when the engine is Postgres. The habit is the same on MySQL: read the plan, do not guess. Which engine you are on is the earlier decision in \u003Ca href=\"\u002Fblog\u002Fpostgresql-vs-mysql-for-applications\" rel=\"noopener noreferrer\">PostgreSQL or MySQL\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>How you know\u003C\u002Fh2>\n\u003Cp>\u003Ccode>EXPLAIN\u003C\u002Fcode> the statement that the slow screen actually runs. \u003Ccode>EXPLAIN ANALYZE\u003C\u002Fcode> belongs on a copy or a quiet window, not as a reflex against production during a sale.\u003C\u002Fp>\n\u003Cp>A sequential scan of a large table, for a filter that should return a handful of rows, is the smell. A scan of a 200-row settings table is fine. Indexing every column is how writes get slower: every insert maintains every index.\u003C\u002Fp>\n\u003Ch2>What we change\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Capture the statement from the slow screen or the slow-query log. Not a hunch about “the database.”\u003C\u002Fli>\n\u003Cli>Read the plan.\u003C\u002Fli>\n\u003Cli>Add the index that matches the filter and the sort.\u003C\u002Fli>\n\u003Cli>Confirm the plan changed.\u003C\u002Fli>\n\u003Cli>Drop indexes nothing uses.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>If the plan is already an index lookup and the screen is still slow, the time is somewhere else: a chatty API, a missing cache, or the browser work in the speed article. Another index will not fix that.\u003C\u002Fp>\n\u003Ch2>Straight next step\u003C\u002Fh2>\n\u003Cp>If one named screen got slower after a year of real data, \u003Ca href=\"\u002Fcontact\" rel=\"noopener noreferrer\">send the query\u003C\u002Fa>. We will read the plan before anyone rewrites the page.\u003C\u002Fp>\n",{"prev":27,"next":45,"related":62},{"slug":28,"title":29,"description":30,"category":31,"readTime":32,"tags":33,"coverImage":36,"coverImageAlt":37,"heroImage":38,"heroImageAlt":37,"metaTitle":39,"metaDescription":40,"ogImage":41,"noindex":19,"published":20,"publishAt":42,"sortOrder":43,"updatedAt":42,"status":23,"path":44},"postgresql-vs-mysql-for-applications","PostgreSQL or MySQL: choose for the workload, not the habit","MySQL is enough for ordinary relational apps. PostgreSQL earns its place with overlap rules, JSON you query, and search in the database.","Engineering",7,[34,35,11],"PostgreSQL","MySQL","\u002Fimages\u002Fjournal\u002Fpostgresql-vs-mysql-for-applications-cover.webp?v=20261013b","Server racks with network cables in a data room","\u002Fimages\u002Fjournal\u002Fpostgresql-vs-mysql-for-applications-hero.webp?v=20261013b","PostgreSQL vs MySQL for Applications | PrimeCode","How to choose PostgreSQL or MySQL for a business application — constraints, JSON, and search — without a benchmark contest.","\u002Fimages\u002Fjournal\u002Fpostgresql-vs-mysql-for-applications-og.webp?v=20261013b","2026-10-09T01:00:00.000Z",49,"\u002Fblog\u002Fpostgresql-vs-mysql-for-applications",{"slug":46,"title":47,"description":48,"category":31,"readTime":9,"tags":49,"coverImage":53,"coverImageAlt":54,"heroImage":55,"heroImageAlt":54,"metaTitle":56,"metaDescription":57,"ogImage":58,"noindex":19,"published":20,"publishAt":59,"sortOrder":60,"updatedAt":59,"status":23,"path":61},"queues-work-outside-the-http-request","Queues: work that does not belong in the HTTP request","The request commits the booking or the order. Mail, PDFs, webhooks, and exports belong on a worker, and that worker must be safe to retry.",[50,51,52],"Laravel","Queues","Architecture","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-cover.webp?v=20261013b","Warehouse aisles of packed orders waiting to move","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-hero.webp?v=20261013b","Queues: Work That Leaves the HTTP Request | PrimeCode","Which web-app tasks belong in a Laravel queue — mail, webhooks, exports — and why a timeout is the wrong place to notice.","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-og.webp?v=20261013b","2026-10-14T01:00:00.000Z",51,"\u002Fblog\u002Fqueues-work-outside-the-http-request",[63,78,95],{"slug":64,"title":65,"description":66,"category":8,"readTime":32,"tags":67,"coverImage":69,"coverImageAlt":70,"heroImage":71,"heroImageAlt":70,"metaTitle":72,"metaDescription":73,"ogImage":74,"noindex":19,"published":20,"publishAt":75,"sortOrder":76,"updatedAt":75,"status":23,"path":77},"laravel-vs-wordpress-performance-philippines","Laravel vs WordPress performance on Philippine mobile","Which stack is faster on mid-range Android and mobile data? Plugin creep vs engineered Nuxt — and the fixes to try before you replatform for speed.",[8,50,68],"WordPress","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-cover.webp?v=20261013b","Code and terminal on a laptop used while reviewing site performance","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-hero.webp?v=20261013b","Laravel vs WordPress Performance Philippines | PrimeCode","Laravel vs WordPress performance for Philippine mobile — LCP, plugin weight, and when caching beats a rewrite.","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-og.webp?v=20261013b","2026-09-16T01:00:00.000Z",39,"\u002Fblog\u002Flaravel-vs-wordpress-performance-philippines",{"slug":79,"title":80,"description":81,"category":8,"readTime":9,"tags":82,"coverImage":86,"coverImageAlt":87,"heroImage":88,"heroImageAlt":87,"metaTitle":89,"metaDescription":90,"ogImage":91,"noindex":19,"published":20,"publishAt":92,"sortOrder":93,"updatedAt":92,"status":23,"path":94},"local-seo-for-philippine-businesses","Local SEO for Philippine Businesses: Google Maps, Reviews, and Service Pages","National SEO is not enough when customers search near them. Here is how Philippine businesses improve local visibility — profiles, reviews, location pages, and site structure.",[83,84,85],"SEO","Local","Philippines","\u002Fimages\u002Fjournal\u002Flocal-seo-for-philippine-businesses-cover.webp?v=20261013b","Local business visibility analytics on laptop screen","\u002Fimages\u002Fjournal\u002Flocal-seo-for-philippine-businesses-hero.webp?v=20261013b","Local SEO for Philippine Businesses | PrimeCode","Local SEO for Philippine businesses — Google Business Profile, reviews, location pages, and how they connect to your website.","\u002Fimages\u002Fjournal\u002Flocal-seo-for-philippine-businesses-og.webp?v=20261013b","2026-08-14T01:00:00.000Z",25,"\u002Fblog\u002Flocal-seo-for-philippine-businesses",{"slug":96,"title":97,"description":98,"category":8,"readTime":9,"tags":99,"coverImage":102,"coverImageAlt":103,"heroImage":104,"heroImageAlt":103,"metaTitle":105,"metaDescription":106,"ogImage":107,"noindex":19,"published":20,"publishAt":108,"sortOrder":109,"updatedAt":108,"status":23,"path":110},"technical-seo-basics-business-owners","Technical SEO Basics Every Business Owner Should Know","Crawlability, sitemaps, canonical URLs, and structured data — technical SEO sounds intimidating but the basics protect your marketing investment. Plain-language guide for decision-makers.",[83,100,101],"Technical","Marketing","\u002Fimages\u002Fjournal\u002Ftechnical-seo-basics-business-owners-cover.webp?v=20261013b","Website analytics and search console metrics on office monitor","\u002Fimages\u002Fjournal\u002Ftechnical-seo-basics-business-owners-hero.webp?v=20261013b","Technical SEO Basics for Business Owners | PrimeCode","Technical SEO basics for business owners — sitemaps, canonical URLs, crawlability, and structured data explained without developer jargon.","\u002Fimages\u002Fjournal\u002Ftechnical-seo-basics-business-owners-og.webp?v=20261013b","2026-08-05T01:00:00.000Z",21,"\u002Fblog\u002Ftechnical-seo-basics-business-owners"]