[Katrinsitter]

C# and SQL Server. Stay away from C, you'll probably just break everything.

[Corporal White]

There needs to be a lot more information.

Certain databases are faster for certain things. Every database can be customized to be much faster at some things than others.

Programming languages are also not so cut and dry. While many people will tell you writing x86 is how you get the fastest code, that's actually not true in the vast majority of cases. If you're in the top 0.5% of developers worldwide with an expertise in x86 and a COMPLETE understanding of the CPU architecture you're targetting, that may be true. But this would mean knowing things about cache line sizes, how to avoid cache misses as much as possible, maintaining data locality, taking advantage of pipelining and multithreading effectively, etc. The vast, vast majority of the time, hand-written x86 will be slower than output from the high-end compilers with full optimization on (especially with profile-guided optimizations). When people start coding on the lowest level, they frequently omit high-level optimizations that the compilers can see.

Even the C vs C++ vs C# thing isn't cut and dry. C will virtually always be faster than C++, but C# can be faster than both. It may sound absurd, but it's true. The .NET CLR is actually extremely good at optimizing the code for your specific computer, taking advantage of all instructions available and not just the lowest common denominator like static code usually has to use. There are numerous examples online of C# outperforming C in some operations.

There's a whole ton of variables to consider here...

[Singukil]

I mean "long-lived" as in "is meant to be online for more than a couple of hours." If you're running it for a few minutes and then shutting it down then things like memory fragmentation (hell, even memory leaks) don't matter, but if it's supposed to be up and running for a week at a time then you want to use C# for most or all of the coding.