I had mistakenly launched a db.r6g.large PostgreSQL instance and deleted it instantly while under Free Tier. I also deleted all the snapshots as well. Yet, I see daily increase in the bill by a few cents. Anyone knows what to do there?
The db.r6g.large database would not qualify for the Free Tier.
Therefore, the bill is showing a charge for the instance that you launched.
Since you turned off the instance and deleted the snapshots, the charges should not increment any more.
Related
In a short time, I will deploy the first version of my web app online. I am using a PostgreSQL database for this project. I have two different choices as database clusters to use: Planescale PostgreSQL, which is free up to 5GB of space, or Digital Ocean cluster, which for 10 gigs costs about 12 dollars a month. The price is not that a big deal, but I think that for at least one year the 5GB plan is more than enough, given that my application will generate almost no revenue.
My question was, how hard can be to move all my data from Planetscale to DigitalOcean or to any other possible provider in the future if more space is needed? Can I do that almost painlessly or I put my data in danger is better to start paying now and don't have problems in the future?
If you have suggestions or recommendations, please, you are welcome
The first question is, when I exceed the free limit, additional fees are applied, or does the application stop working, if additional fees are calculated without my knowledge, tell me how to determine the reading and writing operations for the free limit only, and when I exceed it, the server stops, for example.
Note: The application that you created can be written by everyone without an account, and the data is visible to everyone as well.
When you create new project on firebase, your billing plan is set to "spark", whitch is a start plan. That means, you will not be billed anything, unless you change your billing plan. In this plan, you have 50k reads/writes per day (it was like this a year ago, i am not sure if it wasn't changed). If you exceed this limit, the firebase API's will simply stop responding, so your app won't get any data furthermore that day.
If you want to see your billing plan and daily/monthly usage, go to "usage and billing" in your firebase project overview.
Here is a small screenshot where to find the setting:
I am trying to understand how to lower my Google Cloud SQL bill. I have some databases that are not used frequently and store a modest (100MB) amount of data. I am thinking about stopping the VMs associated with those databases and disconnecting the billing account whenever the application that uses them is not running. Will my data persist even though the vm is off and the billing account is disconnected?
You can stop the instance when you are not using it, and this would stop the billing for it without any worries about the information being deleted. This is mentioned over at this document.
Nevertheless, if you disconnect the billing account from the project for a long period of time, or it remains disabled, the instance may be deleted as mentioned over at this document.
I hope you find this information useful.
I created a simple python flask application with 256MB to play around with.
They state that they give up to 2GB free of ram... so I was way below it
After 30 min I see that I'm billed $0.02..
I tried to post it in their "stackoverflow" variant but I got 500 error :).. so my last resort is to ask here, maybe someone can clarify.
The fear will be to put an app there, forget about it, then at the end of the month you wake up with a $999 bill.
I don't really understand your concern, but I'm still going to try to help.
If you are afraid that you will be charged, this is not going to happen while you have the 30-days trial account. You will only have to pay if you decide to keep the account after the 30-days are over.
If you are afraid that you are being over-charged, you can always keep track of what you spent through the "View Full Usage Details", where there are all the pricing details (per region, per app, etc). You can also predict how much an app will cost beforehand using the calculator on the platform (https://new-console.au-syd.bluemix.net/?direct=classic/#/pricing/cloudOEPaneId=pricing&paneId=pricingSheet)
Lastly, if you are afraid that you will spend more than you want, there is a spending notification policy (which applies only to paid accounts, of course). I believe there is also an option to stop applications if they exceed a limit, but personally I haven't used these feature yet.
I hope this helps :)
I am using iCloud with Core Data, based on the SQLite "Library-style" application design as specified by Apple. While the basic functionality works very well, I am concerned about the transaction logs and how they are managed.
While the database for my app is not large, it is very active and the core data stack is saved many times while the app is in use. I have noticed that a new transaction log is created for every core data save. The end result is that I have a TON of transaction logs and they take up much more space than the actual database.
1) Do the transaction logs ever get automatically pruned / coalesced, or will they continue to grow indefinitely, eventually numbering in the thousands and taking up many megabytes? It seems that the only way to manually purge the transaction logs and recreate a .baseline archive would be to disable and then re-enable iCloud (removing the ubiquity container and starting fresh). But this is obviously not a good solution.
2) My current architecture saves the core data stack often, even for minor changes. In general, this makes sense as my database is small and saving often ensures that the database file is always up-to-date. However, given the above issues with transaction logs, I am thinking that I should perhaps minimize saves to the database. Maybe doing so on a timed basis and/or on app transition states.
3) Even if I minimize the number of transaction logs by reducing how often I save the database, there seems to be an issue here, as the logs will continue to grow in number over time. Eventually the benefit of the "transaction log" design will become a burden in terms of the amount of iCloud storage used and the initial iCloud sync as a new device is added.
As Apple has provided very sparse information on iCloud and almost nothing in the form of "best practices", I would appreciate any insight from the community.
I filed a radar on this issue and received the following reply. They noted that it should be working correctly in iOS 5.1, though I have not yet verified this myself.
A clarification for any who might misunderstand the following. The transaction logs will be cleaned up by the core data internals. This is NOT something that should be performed by the application itself.
Engineering has provided the following feedback regarding this issue:
The transaction logs are intended to be deleted after all the active
peers have had a chance to read them, and they exceed a threshold of
space consumed. There was a previous issue that prevented the devices
from correctly doing so.