QUICK ANSWER
Skelar, a Ukrainian venture builder, publicly hires for both PHP (Symfony) and Go backend roles, and its job posts describe building a new Go payment service for a high-load product. That points to a gradual move, with new services in Go and older PHP systems maintained, not a single rewrite. No official Skelar case study with performance numbers appears to exist. The practical lesson for other teams is the pattern: keep PHP where it earns its keep, build latency-sensitive or high-concurrency services in Go, and migrate one bounded service at a time behind a gateway with measured rollback points.
KEY TAKEAWAYS
• Incremental beats big-bang: Move one bounded service at a time, and keep the PHP version live until the Go version has served real traffic for at least two release cycles.
• Benchmark your own workload: Generic claims of “5x faster” depend on the test. Measure p95 latency and memory per instance on your own endpoints before you commit.
• Budget for people, not just code: Hiring, code review habits, and on-call skills usually cost more than the rewrite itself.
People searching for the “Skelar PHP to Go migration” want to know one thing: did a serious engineering organization actually make this move, and did it pay off? The honest answer has two parts. Some evidence is public. A lot of what circulates online is inference dressed as fact.
This article separates the two, then turns the public signals into a plan you can use if you run a small SaaS, a publishing platform, or a creator tool on PHP.
What Is Publicly Known About Skelar’s Stack
Skelar describes itself as a venture builder, meaning it runs several products on shared infrastructure. Its public job listings give the clearest view of the stack.
One backend team lead posting asks for experience with PHP (Symfony) or Go, or a strong wish to work with that stack. It also lists domain-driven design, microservices, and layered architecture. Another posting for a Go engineer describes building a new version of an existing internal payment service that handles a heavily loaded product. It promises a project without legacy code and freedom to pick tools.
Read those together. The company hires for both languages at the same time. New work, at least in payments, is described in Go. Existing systems still need PHP people.
That is a normal shape for a gradual migration. It is also all the public record proves.
What Is Inferred, Not Confirmed
A third-party blog post presents a full “migration playbook” with tidy benchmark tables. It compares modern PHP with OPcache to recent Go versions on requests per second, memory per connection, and cold-start time.
Treat that post with care. It draws its conclusion mainly from hiring activity, and its figures are generic ranges, not measurements from Skelar’s systems. I found no Skelar engineering blog, conference talk, or postmortem that confirms the numbers. If you quote them in a decision document, label them as industry-typical claims, not Skelar results.
This matters for your own planning. A migration case built on borrowed numbers falls apart the first time a finance lead asks where they came from.
Why Teams Move Backend Services from PHP to Go
Setting Skelar aside, the reasons teams give for this move are consistent.
Concurrency model. Classic PHP-FPM handles each request in its own worker process, so capacity is tied to memory. Go runs many goroutines inside one process, which suits services that hold many open connections or fan out to several upstream APIs.
Startup and footprint. A compiled Go binary starts fast and ships as one file. Container images are small, and a node can often hold more instances.
Static typing. Go catches a class of errors at compile time. PHP has closed much of this gap with typed properties and static analysis tools, but the language still allows looser code paths.
Hiring signal. Some engineers actively seek Go roles. That helps recruiting for new teams and can hurt it for legacy ones.
None of these reasons is a guarantee. Each is a hypothesis to test against your traffic.
Where PHP Still Wins
Many teams migrate too early. Modern PHP is fast enough for most web workloads, and the official PHP OPcache documentation explains how bytecode caching removes repeated compilation on each request. A well-tuned PHP 8 application with caching in front of it handles a surprising amount of traffic.
PHP also has an ecosystem edge for content-heavy products. Frameworks, CMS platforms, and plugin marketplaces save months of work. If your business is publishing, ecommerce content, or a plugin-based SaaS, rewriting the layer that already works is rarely the best use of a small team.
The slow parts of most PHP apps are also not PHP. They are unindexed queries, chatty calls to external services, and missing caches. Fix those first. A Go rewrite of a slow query is still a slow query.
Comparison Table: PHP and Go Trade-Offs
The table compares general trade-offs. It contains no benchmark figures, because results depend on your code, hardware, and database.
| Criterion | Modern PHP (8.x, OPcache) | Go | Practical Note |
|---|---|---|---|
| Request handling | One worker per request | Goroutines in one process | Go helps most with many concurrent connections |
| Memory per unit of concurrency | Higher | Much lower | Measure on your endpoints, not a hello-world test |
| Startup time | Framework boot on each request unless cached | Compiled binary, quick start | Matters most for autoscaling and serverless |
| Ecosystem for content and plugins | Very large | Smaller | PHP wins for CMS-style products |
| Team hiring pool | Large | Smaller but motivated | Plan for training time |
| Deploy artifact | Source plus dependencies | Single static binary | Go simplifies container images |
| Cost of a full rewrite | None | High | Incremental migration lowers the risk |
The rows that hurt are the last two. A binary is easier to ship, but a rewrite is expensive, and the ecosystem gap shows up the day you need a feature PHP already has as a package.
PRACTITIONER TIP
Before you write any Go, record two weeks of real p95 latency and memory per pod for the endpoint you plan to move. Then set a written success rule, such as “p95 drops by 30 percent at equal error rate, or we stop.” Teams that skip this step end up arguing about whether the migration worked because nobody saved the before numbers. Store the baseline in the same dashboard you will use after launch.
The Strangler Pattern in Practice
The safest way to move a live backend is the strangler approach, described clearly in Martin Fowler’s strangler fig application pattern. You grow the new system around the old one and route traffic to it piece by piece until the old parts can be removed.
For a PHP to Go move, the steps look like this.
Step 1: Put a gateway in front
Place a reverse proxy or API gateway in front of the PHP application. At first it forwards everything to PHP. This step alone gives you routing control and better logs.
Step 2: Pick a bounded service
Choose something with clear inputs and outputs. Payments, notifications, search indexing, and webhook processing are common first targets. Avoid the core domain model on day one.
Step 3: Build the Go service with matching behavior
Write contract tests against the PHP service’s real responses. Include the ugly cases: odd encodings, empty arrays that PHP serializes as lists, integer versus string IDs, and timezone quirks. These small differences cause most production incidents in a language migration.
Step 4: Shift traffic in stages
Send 1 percent of requests to Go, compare responses, then raise the share. Keep a one-line rollback in the gateway configuration. Shadow traffic, where Go receives a copy of requests without returning results, catches mismatches early.
Step 5: Retire the old code
Delete the PHP path only after the Go service has run through at least two releases and one peak traffic period. Leaving dead code around invites confusion.
Data and Shared State Are the Hard Part
Language is the easy layer. Data is where migrations stall.
If PHP and Go both write to the same database tables during the transition, you need clear ownership. Decide which service owns each table, and let the other read through an API or a read-only replica. Shared writes with different validation rules produce corrupt records that surface weeks later.
Sessions, queues, and caches need the same attention. PHP’s native session format will not be readable by a Go service, so use a neutral store such as Redis with an agreed format. Job payloads should be JSON with a version field, so either side can evolve without breaking the other.
The Go language’s own guide to effective code is worth reading before your team writes its first service. It covers error handling, interfaces, and concurrency idioms that differ sharply from PHP habits. Teams that skip it tend to write PHP-shaped Go, with deep inheritance-style structures and swallowed errors.
The Real Costs Nobody Puts in the Slide Deck
Rewrites carry costs that benchmark charts hide.
Dual maintenance. During the transition you run two stacks. Every security patch, dependency update, and on-call rotation doubles for a while. Plan for that period to last longer than the estimate.
Skill gaps. A PHP developer becomes productive in Go in weeks, but writing idiomatic, well-tested concurrent code takes months. Pair new Go writers with someone experienced, and budget code review time.
Tooling changes. Debugging, profiling, and deployment all change. Your team needs to learn the profiler, the race detector, and structured logging conventions. Each has a cost.
Feature freeze pressure. Product teams do not stop asking for features because engineering is migrating. Protect a fixed share of capacity for the migration, or it will stall.
Vendor and library gaps. Some PHP packages, especially for content management and third-party SaaS integrations, have no direct Go equivalent. You may write the client yourself and then maintain it.
If your team has fewer than five backend engineers, weigh these costs hard. A focused performance pass on the existing PHP code often delivers most of the gain for a fraction of the effort.
A Decision Checklist for Small Teams
Use these questions before you commit.
- Have you profiled the current system and found the language runtime, not the database or network, to be the bottleneck?
- Do you have a service with a clean boundary that you can move first?
- Can you run both stacks in production for at least six months?
- Does at least one person on the team already write production Go?
- Do you have a written success metric and a saved baseline?
- Can you afford to stop midway if the numbers do not improve?
Answer no to more than two, and the better move is usually to optimize PHP, add caching, and revisit the question in a year.
Measuring Success After the Move
Track four numbers for each migrated service: p95 latency, error rate, memory per instance, and cost per million requests. Compare them against your saved baseline at 30, 60, and 90 days.
Watch cost carefully. Go often uses less memory, but you may spend more on engineering time, monitoring tools, or a second deployment pipeline. A migration that saves 20 percent on servers and costs 200 percent more in engineer hours is a loss.
Also record developer experience. Ask the team whether deployments feel safer, whether bugs are easier to trace, and whether onboarding got faster or slower. Those answers decide whether the migration lasts.
Final Thoughts
The Skelar case is useful, but not for the reason most articles claim. The public record shows a company hiring in both languages and building new work in Go, not a documented triumph with published numbers. That is the more realistic model for most teams.
Keep PHP where it works. Build new, concurrency-heavy services in Go. Move one boundary at a time, save your baseline, and hold yourself to a written success rule. Migrations that follow that discipline tend to finish. The ones driven by borrowed benchmarks tend to stall.
Frequently Asked Questions
Did Skelar fully replace PHP with Go?
Public evidence says no. Job listings show ongoing hiring for PHP (Symfony) and Go, with new services such as a payment platform described in Go. That fits a gradual approach.
Are the “5x faster” figures for Go reliable?
They are generic ranges, not Skelar measurements. Results vary with workload, database design, and how well the PHP side is tuned. Run your own tests.
Should a solo founder migrate from PHP to Go?
Usually not. Optimize queries, add caching, and improve deployment first. Consider Go for a single high-concurrency service if you have a clear need.
What is the best first service to migrate?
Pick something bounded and observable, like webhook processing or notifications. Avoid anything tied to your core data model.
How long does a gradual migration take?
For a mid-size application, plan on many months, with the first service live in one to three months and full retirement of the legacy path much later.
