In general, if you want to learn a new language, pick a project of limited scope (weeks) that you have done in the past in some other language.
A database is a bad choice. Even the simplest database worth being called a database requires months of effort.
1. You need to store all your data in "pages". These are fixed-length blocks (that can be chained together).
2. Use a classical "dictionary" data structure to store your index (most use B-Tree), but you place that structure on-disk instead of in-memory. Your index basically points a key to the index of the first page that contains the value.
3. You may need to store other types of data in the file, such as the free page list.
As for geo-location, B-Tree fits nicely here.
1. Intelligently lay out your B-Tree so that nearby nodes are typically within the same node-family-system. Include information about the distance spanned by descendants in the tree (you probably want to use Manhatten distance).
2. When trying to do "near" queries, first locate the node you are interested in and then start traversing up the parents until you find the ancestor that encompasses the distance you are looking for.
3. Grab all the descendants of that ancestor and re-check them against the distance.
If you want to get comfortable with a language that you are learning my advice would be to pick a simple real-world problem and to try to solve that rather than to tackle a major project like this. That will only cause frustration in the long run.
Start with downloading the source code for say MariaDB, reading internals documentation on project Wiki, compiling it on your machine.
https://wiki.postgresql.org/wiki/Developer_FAQ#How_do_I_get_...
https://mariadb.com/kb/en/contributing-code/
Good luck.
Now, C is a shotgun that you will invariably use to shoot yourself in the foot with, but I think it's absolutely straightforward and powerful manual memory management, as well as raw speed, would make it worth learning.
Like, you could for example just focus on building a database of a given size, in memory -- you could even do it all in RAM, if you wanted.
You could have the database specialize in holding one kind of data structure (for example, how about tries? they're pretty rare, despite how useful they are)
And yeah, with such a specific goal, you could very well make a very nice niche DB that optimizes for the kind of data you're trying to search! Especially with map data becoming more and more important, I think it's actually a pretty awesome idea.
However, I would say that you should go in with the intent to make a kickass latitude-longitude database, rather than just having it be a piece of something you're trying to push to production (you have better things to worry about with something that's going to production -- don't make the db one of them)
You never know, you might find that the database is the more important project!
Production-ready, simple, written by you: pick 2. The 'correct' thing to do is choose the first two. Have at it.
Start with something very simple - maybe a single table with a hardcoded schema, or a simple string key/value store (a la memcached). Find a use case for which this is an improvement over what you had before. Add features as and when you need them.
You should try to limit what you build though. Can you utilize leveldb, Riak, Cassandra, Redis or even Postgres Foreign Data Wrapper.
Your data will probably need to be queried with other user data so consider that as well.
I would start with figuring out how to query the data you need that different from the current measures and prove to yourself that it beats out the existing strategies. If it does then expand by storing and loading the data to disk.
then work on connecting to it through multiple clients, look into using msgpack, thrift, message pack.
Have fun.
If you run any of the big EMC, or NetAPP, or Exadata systems those are built with many of the core components written in Assembly.